Festplatten als Bremse

Den Titel "RAM- und I/O-Sau" haben sich Datenbanken durchaus redlich verdient. Dabei sind Lese- und Schreibgeschwindigkeit teuer, und genau deshalb sparen hier Hardwarehersteller gerne. Bei Hardwarekäufen ist ein gesundes Misstrauen grundsätzlich angebracht, denn der Verkäufer verfolgt naturgemäß eigene Interessen. Eigene Hardware-Benchmarks sind zwingend erforderlich. Auf jeden Fall sollte der Käufer darauf bestehen, dass er Hardware zurückgeben kann, die nach eigenem Benchmarking seinen Erwartungen nicht entspricht.

Spätestens wenn die Datenbank so groß geworden ist, dass sie nicht mehr vollständig in das RAM passt und manchmal sogar schon vorher, werden die Festplatten zur Bremse. Daher sollten die Platten sorgfältig auf vier Faktoren hin getestet werden:

• sequenzielle Lesegeschwindigkeit (read),
• sequenzielle Schreibgeschwindigkeit (write),
• Geschwindigkeit bei zufällig verteilten Zugriffen (Random I/O) und
• Commit-Rate.

Die Commit-Rate gibt an, wie schnell Daten permanent auf die Platte geschrieben werden. Ist die Geschwindigkeit erheblich höher als erwartet, ist das ein Zeichen dafür, dass ein Write-Cache die Daten zwischenspeichert, was bei Absturz oder Ausfall des Systems zu Datenverlusten führen kann. Wenn kein flüchtiger Speicher vorhanden ist, dann ist die Commit-Rate der Platte gleich der IOPS-Rate (I/O operations per second). Selbst sehr teure Disk-Array-Hardware wie SAN oder NAS kann Schwächen in einer der Disziplinen haben, die für Datenbanken besonders wichtig sind. Auch hier sind also vorherige Tests unabdingbar.

Die sequenzielle Lese- und Schreibgeschwindigkeit lässt sich unter UNIX einfach mit Tools wie »dd« testen. Um ein brauchbares Ergebnis zu bekommen, sollte hierbei natürlich sichergestellt werden, dass mehr Daten geschrieben werden, als in den RAM passen. Die meistverbreitete Anwendung zum Testen dieser Leistungsfaktoren ist der Benchmark Bonnie++. Einige der Tests, etwa das zeichenweise Lesen und Schreiben, sind aber für Datenbanken belanglos. Dagegen führt ein Aufruf wie

bonnie++ -f -n 0 -u root

zu einem Ergebnis, das Tests vermeidet, die für Datenbanken nicht relevant sind.

Die Random-I/O-Seeks können mithilfe des Programms »sysbench« getestet werden. Dieser ursprünglich für MySQL entworfene Benchmark ist aber für PostgreSQL erst relativ aufwendig anzupassen..

Drei Vergleichswerte von realen Systemen:

• Ein einfaches 2-Platten RAID1-Array mit 15000 U/min SAS Festplatten, 80 MByte/s sequenzielle Schreibzugriffe und 110 MByte/s Lesezugriffe.
• Ein 20-Platten-RAID10-Array mit gleichen Festplatten, 630 MByte/s sequenzielle Schreibzugriffe und 950 MByte/s Lesezugriffe.
• Ein SSD der Intel 320 Serie, 120 GByte Kapazität. 150 MByte/s sequenzielle Schreibzugriffe und 250 MByte/s Lesezugriffe.

Allein durch Testen der sequenziellen Lese- und Schreibgeschwindigkeiten lassen sich schon einige Hardwareprobleme erkennen. Allerdings sind Zugriffe der Datenbank selten sequenziell, sondern meist zufällig verteilt. Wie der Suchdurchsatz mit steigender Threadanzahl bei Random-I/O skaliert, zeigt die Abbildung 2 .

Abbildung 2: So skalieren zufällige Suchoperationen mit steigender Anzahl Threads auf verschiedenen Speicherlösungen.

Lohnen SSDs?

Zu erkennen ist hier, dass die regulären SAS-Platten nur eine Transferrate von 1,5 MByte/s bei zufällig verteilten Daten haben. Bei mehreren zeitgleichen Zugriffen kann der Plattenkopf mehr passende Daten beim Überfahren der Platte einsammeln. Wenn ein Lagerist beim Durchkämmen des Lagers gleich Material für mehrere Aufträge zusammenstellt und in passende Fächer auf seinen Wagen legt, ist er auch schneller, als wenn er für jeden Auftrag einzeln loszieht.

Die Abbildung zeigt, dass bei 20 zeitgleichen Anfragen das Zwei-Platten-Array 5 MByte/s und das 20-Platten-Array 10 MByte/s erreicht. Das ist ein gewaltiger Unterschied gegenüber der sequenziellen Suchgeschwindigkeit. Das einzelne SSD sticht die Mitbewerber in dieser Disziplin ganz klar aus. Aber das Blatt kann sich auch schnell wenden. Sobald es um sequenzielle Zugriffe geht, reichen schon wenige reguläre Platten in einem Verbund aus, um das SSD zu übertrumpfen. Im Vergleich mit großen Arrays gerät das SSD dabei dann endgültig ins Hintertreffen.

Die Entscheidung zwischen SSD und regulären Platten ist nicht einfach. Es gilt hier, zwischen sequenziellen und zufällig verteilten Zugriffen abzuwägen. SSDs sind bekannt dafür, gut im Halten von Datenbankindizes zu sein, da diese meist zufällig verteilt sind, und es hier zu massiven zufällig verteilten Schreibzugriffen bei der Ausführung von Update-Operationen kommen kann.

Die Auswahl der richtigen Hardware kann entscheidend sein, um mit PostgreSQL eine gute Leistung zu erzielen. Eine weitere, ausschlaggebende Komponente für gute Schreibgeschwindigkeit ist der batteriegestützte Schreibpuffer (Write Cache), der üblicherweise auf RAID-Controller-Karten zu finden ist. Es ist wärmstens zu empfehlen, dass das SSD eine Batterie für den Write Cache hat. Mit einem guten Write Cache kann PostgreSQL bis zu hundertmal höhere Transaktions-Commit-Raten erzielen. Server mit flüchtigem Write Cache (ohne eine Batterie) oder Controller, die behaupten, dass die Daten geschrieben wurden, ohne sicherzustellen, dass sie sich wirklich auf der Platte oder im batteriegestützten Cache befinden, können bei einem Absturz die Datenbank korrumpieren.