Johannes Truschnigg - SRE & DevOps


Zur Suche ▼Zum Archiv ▼

Eintrag von 2009-11-22

Solid State Disks - Hype oder Muss?


Solid State Disks (auch Solid State Drives, kurz SSDs) sind schon seit geraumer Zeit in aller Munde. Während nämlich Prozessoren, Caches, Hauptspeicher und sogar Netzwerkanbindungen in den letzten Jahrezehnten um Größenordnungen schneller geworden sind, hat sich bei rotierenden, magnetischen und/oder optischen Medien vergleichsweise wenig getan. SSDs brechen nun endlich mit dieser lange währenden Tradition.

Aktuelle Festplatten lesen und schreiben sequentiell über 100MiB/s, und die mittlere Zugriffszeit bewegt sich - wenn man von in der Realität erreichten Werten ausgeht, die so nicht unbedingt in den Hersteller-Datenblättern auftauchen - im Bereich um 10ms. Das klingt nach viel bzw. wenig, aber vor allem der zweite Wert, die vergleichsweise lange mittlere Zugriffszeit, führt in der Praxis oft zu lästigen Wartepausen.

Bei einem rotierenden, magnetischen Medium wie einer Festplatte führt jeder Zugriff auf das Dateisystem zu einer Bewegung von Plattern und Leseköpfen: ein komplexes System aus Dateisystem, Platten-, Controllertreiber und Firmware übersetzt die Anforderung von Dateien in das Auslesen physikalischer Positionen auf den Magnetscheiben des Datenträgers. Über viele Jahre hat man tausende Mannstunden in Algorithmen und Kniffe zur effizienten Allokation von physikalisch günstig zueinander gelegenen Blocks schon beim Schreiben investiert, um die so notwendigen Bewegungen auf ein Minimum zu reduzieren, und damit hohe Arbeitsgeschwindigkeit zu gewährleisten. Nicht alle dieser Strategien sind für bestimmte Workloads geeignet: in einem Fileserver etwa will man hohen maximalen Durchsatz, und ein paar Millisekunden mehr Latenz nimmt man dafür gerne in Kauf. Ein großer Mailserver mit zigtausenden Mails in einem Spool-Verzeichnis kann sich solche Verzögerungen nicht leisten, und der Kompromiss kippt zugunsten von mehr, aber kleineren Lesevorgängen pro Zeiteinheit. Durch geschickte Wahl von Dateisystem, Mount-Optionen und IO-Scheduler kann man hier erstaunliche Leistungssteigerungen erzielen.

Besonders fällt oftmals die mittlere Zugriffsgeschwindigkeit ins Gewicht: wenn viele Dateien in einem Verzeichnis existieren, so wird i. A. für jede dieser Dateien mindestens ein eigener Lesezugriff getätigt, wenn diese z. B. gelistet (`ls -l` oder opendir(3)/readdir(3)) werden. Wenn man von 1.000 Dateien in einem Verzeichnis und einer mittleren Zugriffszeit von 10ms ausgeht, so dauert diese Operation rund 10.000ms, also geschlagene zehn Sekunden. Mein Home Directory beinhaltet momentan knapp unter 690 Inodes, hier fällt diese Rechnung also schon recht deutlich ins Gewicht. Dass es in der Realität trotzdem nicht jedes Mal so lange dauert, bis Konqueror mir den Inhalt dieses Verzeichnisses präsentiert, liegt am aggressiven Filesystem-Caching des Linux-Kernels. Viele Charakteristika der Dateien in einem Dateisystem hält der Kernel im Hauptspeicher das Systems vor.

Vor allem hier (und ganz besonders ohne entsprechende Cache-Inhalte) kommt eine spezifische Eigenschaft von SSDs ins Spiel: Aufgrund ihres inneren Aufbaus (NAND-Bausteine anstatt magentischer Platter) kommen sie ohne bewegliche Teile aus, und die mittlere Zugriffszeit dieser Bauelemente liegt nicht wie bei Festplatten im Milli-, sondern im Mikro- bis Nanosekundenbereich. Populäre Programme zum Benchmarken von Blockgeräten sind meist noch nicht auf diese neue, für sie "unerwartete" Größenordnung vorbereitet, und weisen deshalb einfach 0.1ms als mittlere Zugriffszeit für SSDs aus. Selbst wenn man von diesen ziemlich grob approximierten 100 Mikrosekunden ausgeht, würde das die Laufzeit aus dem obigen Beispiel von 10 Sekunden auf 0.1 Sekunden reduzieren, das Listen braucht also um den Faktor 100 weniger Zeit. Die verkürzte Wartezeit ist subjektiv kaum wahrnehmbar - ein deutlicher Gewinn gegenüber der ursprünglichen, zehnsekündigen Zwangspause im Arbeitsfluss.

Aktuelle SSD-Generationen haben mittlerweile auch prinzipbedingte Probleme wie langsame sequentielle oder wahlfreie Schreibzugriffe sehr gut im Griff, und mit dem ATA-T13-Standard TRIM ist demnächst auch für gleichbleibend hohe Performance über die gesamte Lebensdauer einer SSD gesorgt.

Ich persönlich habe trotz dieser rosigen Aussichten erst einmal klein angefangen, und für mein treues Lenovo Thinkpad x200 ein relativ günstiges 40GB Kingston-SSD mit empfehlenswertem Intel-Controller angeschafft: Ein Kingston SSDNow! SNV125-S2. Auch wenn diese nicht ganz die Leistung anderer (mindestens doppelt so teurer) Geräte (ebenfalls mit Intel-Controller) erreicht, ist der Unterschied zu meiner alten 250GB SATA-300 Platte mit 5.400RPM enorm: Xorg startet nun knappe zehn Sekunden nach dem Einschalten des Notebooks, und auch meine X-Session ist in einem Bruchteil der Zeit geladen, die ich zuvor gewöhnt war. Selten zuvor habe ich knapp 80 Euro so gut in Hardware investiert.

Um das Optimum aus einer Solid State Disk unter GNU/Linux herauszuholen sollte man sich idealerweise schon vor dem ersten Beschreiben des Datenträgers unbedingt diesen Artikel von Ted Tso zu Gemüte führen, und für die SSDs im System den noop- oder deadline-IO-Scheduler verwenden.

direkter Link ▲

© 2007-2019 Johannes Truschnigg | valid xhmtl & css