I/O-Monitoring

Um das Zusammenspiel all dieser Komponenten beurteilen und einen möglichen Engpass diagnostizieren zu können, bedarf es konkreter Messwerte, die etliche Linux-Monitoringtools auch bereitwillig liefern.

vmstat ist eines dieser Kommandos. Mit der Option »‑D« produziert es zunächst eine brauchbare Übersicht über den Status des I/O-Subsystems insgesamt und reportiert unter anderem die seit dem letzten Booten ausgelösten Lese- und Schreiboperationen nach Anzahl und Sektoren sowie die dafür jeweils benötigte Zeit. Die Option »‑p« kann diese Statistik auf eine anzugebende Partition herunterbrechen. Ohne Optionen, dafür mit zwei optionalen Parametern für Anzahl und Dauer eines Wiederholungsintervalls gestartet, liefert »vmstat« auch Werte für die Auslastung des Disk-Cache.

iostat ist der eigentliche Spezialist für I/O-Statistiken. Aufgerufen mit der Option »‑x« erstellt es eine erweiterte Plattenstatistik, die oft bereits auf den ersten Blick Flaschenhälse offenbart. Die Bedeutung der verwendeten Abkürzungen erklärt Tabelle 1. Stößt man beispielsweise auf eine übervolle Request-Queue, ist die Wartezeit sehr viel größer als die Servicezeit der Platte und liegt die Auslastung nahe 100 Prozent, dann arbeitet die Disk an ihrer Leistungsgrenze.

sar , der System Activity Reporter, gehört auch oft zum Standard-Handwerkszeug des Performance-Analysten unter Linux. Im Unterschied zu den oben vorgestellten und etlichen anderen Tools ermöglicht er Langzeitbeobachtungen und versieht seine Messwerte mit einem Zeitstempel. Für die Plattenstatistik ist »sar ‑d« zuständig.

lsof Häufig reicht es aber nicht, nur die Menge der gelesenen oder geschriebenen Sektoren und den Zeitbedarf zu ermitteln, sondern es interessiert auch die Quelle. Hier hilft das Utility »lsof« (List Open Files) weiter. Zusammen mit »+d« durchsucht es ein anzugebendes Verzeichnis samt aller Unterverzeichnisse und gibt aus, welche Prozesse die darin enthaltenen Files gerade geöffnet haben (Abbildung 3). Die Option »+D« bewirkt dasselbe, ohne aber in Subdirectories abzusteigen.

Abbildung 3: »lsof« zeigt hier, welche Prozesse gerade Dateien unter »/var/log« geöffnet haben.

Leider gab es jedoch unter Linux lange keine Möglichkeit, das I/O-Volumen eines Prozesses separat zu betrachten. Andere Unix-Varianten – beispielsweise FreeBSD – kennen einen Standard-Format-Specifier für das Kommando »ps«, der die von jedem Prozess gelesenen und geschriebenen Blöcke anzeigt. Der Linux-Kernel unterstützte dieses nützliche Feature leider lange nicht. Neuere Versionen des Sysstat-Pakets enthalten das Kommando »pidstat«, das diese Werte nachreicht. Es gibt pro Prozess die mit den Platten ausgetauschte Datenmenge aus.

blktrace : Allerdings kann man sogar einen einzelnen I/O-Request beobachten, auch wenn das eher in das Ressort Debugging statt Performance-Monitoring fällt. Das Utility »blktrace« [1] erlaubt einen Blick auf die Interna des Block I/O Layers. Während »iostat« und Verwandte für die Verweildauer der Requests in den Warteschlangen nur summarische Werte ausgeben, kann »blktrace« einen einzelnen Request verfolgen und beispielsweise berichten, wie lange er sich in einer Queue befand, ob er dort umsortiert wurde, und so weiter.

I/O-Tuning

Sind Messwerte gesammelt, die Aufschluss über die Befindlichkeit des I/O-Subsystems geben, beginnt das Nachdenken über konkrete Maßnahmen. Am Ende muss eine individuelle Lösung stehen, die möglichst alle Komponenten umfasst und sich an den jeweils durch Applikation und Anwender bestimmten Zielen ausrichtet. Dafür gibt es ein paar Richtlinien:

Lastverteilung ist häufig ein Weg zu besserer Performance. Dabei gilt es, I/O-intensive Teile der Applikation zu isolieren und ihnen auf eigenen Partitionen oder besser noch Platten optimale Bedingungen zu schaffen. Das gilt etwa für die Redo-Logs einer Datenbank, die man besser nicht mit den eigentlichen Daten in einem Filesystem zusammenbringt. Auch helfen hier mehrere Platten, Engpässe auf einem Device zu umgehen.

Filesysteme sind ein anderer Ansatzpunkt. Das beginnt schon bei ihrer Auswahl, denn nicht jedes taugt für jeden Zweck. Ein brauchbares Allround-Filesystem – deshalb auch Standard in vielen Linux-Distributionen – ist beispielsweise Ext3. Für sehr I/O-lastige Prozesse sind aber eher ReiserFS oder XFS geeignet. Braucht die Applikation dagegen vor allem Rechenzeit, dann ist ein Filesystem gefragt, das die CPU wenig belastet. Hier kann JFS eine gute Wahl sein. Die meisten Filesysteme lassen sich außerdem über Parameter tunen. Erhöht man etwa die Blockgröße, steigt zwar der Verschnitt, weil dann im Extremfall für ein einziges Byte mehrere Kilobyte belegt werden, gleichzeitig verbessert sich aber die Effizienz beim Lesen großer Dateien.

Noatime Nicht immer sind Zeitstempel für das letzte Zugriffsdatum nötig. Die Mount-Option »noatime« schaltet die Aktualisierung dieses Datums ab. Das bringt speziell bei vielen kleinen Dateien, die ohne die Atime auskommen – etwa in Caches, Proxies, Mail- und News-Verzeichnissen, bei Webseiten – erhebliche Performance-Gewinne.

Scheduler Wegen der Komplexität der Verhältnisse sind bei der Wahl des Scheduling-Algorithmus oft Experimente nötig. Die aber können durchaus ergeben, dass der raffinierteste Algorithmus beileibe nicht immer der günstigste ist. Im Gegenteil: Eine Studie von IBM zur Eignung der I/O-Scheduler [2] hat beispielsweise ans Licht gebracht, dass gerade der dümmste Scheduler »noop« in Konfigurationen mit sehr vielen Platten die besten Ergebnisse bringt, weil alle anderen im Optimierungseifer unter diesen Umständen zu große und schwerfällige Kontrollstrukturen aufbauen.

Hardware hat, wie oben schon erwähnt, natürlich einen entscheidenden Einfluss auf die Performance: Sie markiert die Ecksteine. Wo es auf höchste Leistung ankommt, da führt auch heute noch kaum ein Weg an Enterprise-Platten vorbei (meist mit SCSI-, SAS- oder FC-Interface). Sie sind schon wegen ihrer höheren Drehzahl schneller und außerdem weniger störanfällig.

Das beweist ein Blick in die Datenblätter: Eine 160-GByte-Seagate-Platte für den Massenmarkt mit SATA-Schnittstelle bringt es bei 7200 RPM etwa auf eine Latenz von 4,16 ms und schafft eine maximale Transferrate von 300 MByte/sec. Eine vergleichbar große Platte aus der Cheetah-Serie desselben Herstellers mit 320-UW-SCSI dreht aber mehr als doppelt so schnell und verringert die Latenz auf 2 ms, die maximale Transferrate liegt bei 1600 MByte/sec. Auch die Wahrscheinlichkeit nicht behebbarer Lesefehler ist hier um zwei Zehnerpotenzen kleiner. Allerdings kostet das Hochleistungsmodell etwa um 200 Euro, die billigere Ausführung weniger als die Hälfte.