Mietserver mit Solid State Disk versus Festplatte im Benchmark

Lohnt es sich, in Servern schon auf teure Flashspeicher zu setzen? Ist der Performancegewinn so groß, dass er die Mehrkosten rechtfertigt? Um das herauszufinden, orderte die Redaktion beim Hoster Strato [1] zwei identische Server. Beide mit einem Quadcore-AMD-Opteron-1389-Prozessor (2,9 GHz) und 8 GByte Arbeitsspeicher, beide unter Ubuntu 10.04 LTS. In eines der beiden Geräte war eine schnelle 160-GByte-Intel-SSD eingebaut, der andere verfügte stattdessen über zwei gespiegelten Terabyte-Festplatten.

Hätten sich die Tester beim zuletzt erwähnten Gerät mit 4 GByte RAM begnügt, wären die Systeme gleich teuer gewesen, so aber war der Festplatten-Server mit knapp 100 Euro pro Monat 20 Euro teurer als sein Gegenstück mit einer SSD. Das Größenverhältnis der Massenspeicher bei ähnlichem Endverbraucherpreis spiegelt dabei zumindest ungefähr die Kostenrelation wider, die der Vermieter weitergibt: 160 GByte SSD entsprechen 2 Terabyte HD, die nur ein Zehntel kosten.

Zunächst einmal galt es, sich etwas zu überlegen, um trotz der üppigen Ausstattung mit RAM die tatsächliche Leistung der Massenspeicher ermitteln zu können. Ansonsten würden nämlich die allermeisten Zugriffe aus Caches bedient, für die Linux normalerweise fast den gesamten freien Hauptspeicher verwendet. Unterschiede wären dann kaum feststellbar und eher zufällig.

Vorbereitungen

Um das zu vermeiden, richteten die Tester der Redaktion auf beiden Servern große RAM-Disks ein, die nur rund 1 GByte übrig ließen. Allerdings kann dieser Trick nur gelingen, wenn der Admin beim Einrichten der platzverdrängenden Speicherfestplatte aufpasst. Verwendet er dafür nämlich »tmpfs«, dann würde der Platz zum einen nicht dynamisch belegt - es würde nie mehr RAM verbraucht, als beim Mounten angegeben -, zum anderen müsste der Rechner bei einer vollen Platte beginnen zu swappen. Beides kann in vielen Situationen durchaus ein Vorteil sein, für die hier angestrebten Zwecke aber wäre es ein handfester Nachteil. Stattdessen kam im hier geschilderten Fall »ramfs« zum Einsatz:

mount -t ramfs -o size=5500m ramfs /ramdisk

Eine solche RAM-Disk wächst auch über die hier angegebene Größe hinaus, solange Speicher frei ist, und sie führt nie zum Swappen. Erzeugt man auf diesem rund 5,5 GByte großen Medium und mit über 7 GByte freiem RAM im nächsten Schritt etwa ein 6 GByte großes File, findet auch das Platz:

server:/ramdisk# dd if=/dev/zero 
of=./bigfile bs=1048576 count=6000

Damit ist nur noch rund 1 GByte RAM verfügbar, und Benchmarks, die Testfiles erzeugen müssen, die größer als der freie Hauptspeicher werden, haben jetzt eine reelle Chance, in endlicher Zeit zum Ziel zu kommen.

Erst einzeln

Für die geplanten Messungen bieten sich zwei prinzipiell verschiedenen Strategien an. Einmal kann man die reine I/O-Leistung, also den Durchsatz von Festplatte und SSD, isoliert messen. Im Ergebnis eines solchen so genannten Single Component Benchmark würde deutlich, wie viel schneller der eine oder andere Massenspeicher ist.

Der Vorteil dieser Methode ist, dass sie den fraglichen Faktor isoliert. Zugleich ist das allerdings auch ihr größter Nachteil, denn in der Praxis spielen immer andere Einflüsse mit hinein und bestimmen die für den Anwender entscheidende Performance der Applikation mit. So liest keine echte Anwendung ständig riesige Files am Stück, stattdessen mischen sich Lese- und Schreiboperationen mit Pausen, werden mal kleinere, mal größere Stücke, mal zusammenhängende, mal verstreute Sektoren angesprochen.

Das berücksichtigen gute Einzelkomponententests, indem sie verschiedene Operationen und Recordgrößen nacheinander testen. Im wirklichen Leben können sich aber Beschleunigungs- und Bremseffekte aufeinander aufbauender Komponenten potenzieren. Diesem Effekt und damit der Gesamtperformance eines Programmverbunds spüren so genannte Full Stack Benchmarks nach, die reale Softwaresysteme imitieren.

Im SSD-HD-Duell interessierte zunächst nur die Plattenperformance. Für deren Messung bot sich das bewährte IOzone [1] an, das automatisch über verschiedene File- und Record-Sizes sowie alle möglichen Operationen des Device iteriert (Read, Write, Re-Read, Random Read und so weiter). Wichtig dabei ist, dass die größten Testfiles ein Mehrfaches des verfügbaren RAM betragen. Das stellt sicher, dass bei diesen Files die Daten nicht mehr aus Caches stammen und dass IOzone die tatsächliche Gerätegeschwindigkeit misst, die so genannte Spindle Speed. In Abbildung 1 zeigen diese die beiden letzten Säulenreihen, die rechts hinten nur wenig hervorlugen. Alles andere sind gepufferte Operationen.

Abbildung 1: Nur die beiden letzten Messreihen reflektieren die so genannte Spindle Speed (hier beim Lesen von der SSD), alle anderen zeigen gepufferte Operationen.

Betrachtet der Tester nun die 4-GByte-Testfiles beim Lesen und Schreiben von HD beziehungsweise SSD einzeln, erhält er eine Statistik, wie sie die Boxplots in Abbildung 2 wiedergeben. Die Kästen stehen für den Bereich, in den die Hälfte der Messwerte fällt, die sich um den Wert in der Mitte der Messreihe (Median) gruppieren, den in der Grafik der Querstrich in der Box symbolisiert. Die Querstriche unter und über der Box stehen für Minimum und Maximum, die gestrichelten Verbindungslinien zur Box symbolisieren also die Spannweite der Messwerte über alle Record-Sizes.

Auf den ersten Blick erkennbar ist: Lese- und Schreibgeschwindigkeit der Festplatte liegen sehr nahe beieinander und streuen auch etwa im selben Bereich. Das Schreiben auf SSD ist etwas langsamer, aber nicht sehr viel. Allerdings könnte sich die Schreibperformance bei längerem Gebrauch deutlich zu Ungunsten der SSD entwickeln, was auch aus zahlreichen Anwenderberichten hervorgeht. Der Grund dafür ist, dass ein SSD-Laufwerk die Speicherzelle einer gelöschten Datei nicht wie eine Festplatte direkt mit neuen Inhalten belegen kann, sondern vorher erst tatsächlich leeren muss. Das erklärt unter Umständen den doppelten Aufwand beim Schreiben.

Die Lesegeschwindigkeit der SSD hätte bei einer maßstabsgerechten Darstellung die Grafik in Abbildung 2 gesprengt. Sie liegt rund beim Doppelten der Festplattenperformance.

Abbildung 2: Die Boxplots zeigen auf einen Blick die Lage und Verteilung der Benchmarkergebnisse. Das Lesen von SSD ist so schnell, dass das Layout keine maßstäbliche Darstellung mehr zulässt.