Disk-I/O-Latenz mit iostat -x: r_await, w_await, aqu-sz und warum %util bei SSD und RAID in die Irre führt

Worum es geht

iostat -x (sysstat) ergänzt die einfache Ansicht des Lese-/Schreibdurchsatzes um erweiterte Spalten pro Gerät. Das Manual definiert die für die Latenzanalyse wichtigsten Felder: r_await und w_await sind die durchschnittliche Zeit in Millisekunden, bis Lese- bzw. Schreibanfragen bedient wurden, einschliesslich Wartezeit in der Queue und Bedienzeit; aqu-sz ist die durchschnittliche Länge der Queue der an das Gerät gesendeten Requests; %util ist der Prozentsatz der verstrichenen Zeit, in der I/O-Requests an das Gerät gesendet wurden.

Die Spaltennamen hängen von der sysstat-Version ab. Ältere Versionen (etwa sysstat 10.x unter RHEL 7) geben avgqu-sz, avgrq-sz (in Sektoren) und svctm aus, ein Feld, dem laut dem eigenen Manual schon damals nicht zu trauen war; aktuelle Versionen nennen diese Felder aqu-sz und areq-sz/rareq-sz/wareq-sz (in Kilobyte) und dokumentieren svctm nicht mehr. Ob neben r_await/w_await in der -x-Ausgabe zusätzlich eine kombinierte Spalte await erscheint, hängt ebenfalls von der Version ab. Skripte sollten Felder daher anhand des Spaltenkopfs und nicht anhand der Spaltenposition zuordnen.

Warum es wichtig ist

Die Aufteilung von await in Lesen und Schreiben ist wichtig, weil sich beide auf demselben Gerät stark unterscheiden können, etwa bei sequenziellen Schreibzugriffen, aber zufälligen Lesezugriffen auf einer rotierenden Festplatte. Ein einzelner gemischter Durchschnitt verdeckt das. aqu-sz zählt die am Gerät ausstehenden Requests, einschliesslich derer, die gerade bedient werden. Bei einem Gerät, das jeweils nur einen Request bearbeitet, bedeutet ein Wert, der dauerhaft über etwa eins liegt, dass sich Requests stauen. SSDs, NVMe und RAID-Verbunde bedienen viele Requests parallel, daher ist dort ein höherer aqu-sz normal und nur relevant, wenn er gemeinsam mit await steigt. %util war ein verlässliches Sättigungssignal bei Geräten, die nur einen Request gleichzeitig bedienen können. Das Manual hält ausdrücklich fest: Bei Geräten, die Requests seriell bearbeiten, tritt Sättigung auf, wenn der Wert nahe 100 % liegt; bei Geräten mit paralleler Bearbeitung – als Beispiele nennt es RAID-Arrays und moderne SSDs – spiegelt dieser Wert die Leistungsgrenzen nicht wider, denn ein solches Gerät kann bei 100 % liegen (nie im Leerlauf sein), obwohl es von seiner tatsächlichen Durchsatz- oder Latenzgrenze weit entfernt ist.

So wird es angewendet

• Für die für Anwender spürbare Latenz zuerst r_await/w_await lesen und am erwarteten Bereich des jeweiligen Speichers messen, nicht an einem festen Wert für unterschiedliche Geräte.
• Beobachten, ob aqu-sz über aufeinanderfolgende Messungen gemeinsam mit steigendem await zunimmt, und dies an dem messen, was für das Gerät normal ist.
• %util bei SSD, NVMe und RAID als Aktivitätsindikator behandeln, nicht als Sättigungsprozentsatz; ein schnelles Gerät bei 100 % mit niedrigem await ist nicht der Engpass.
• Wiederholt messen (iostat -xz 1 10) statt einmalig; der erste Bericht deckt die Zeit seit dem Systemstart ab, nicht das Messintervall (-y lässt ihn weg).
• Auf ein einzelnes Gerät eingrenzen (iostat -x <device> 1), sobald sich in der vollständigen Liste ein Kandidat abzeichnet.

Stolpersteine

• Alarmierung allein auf %util bei modernem Storage, wodurch echter Queue-Stau, den aqu-sz gezeigt hätte, übersehen wird.
• await über unterschiedliche Geräte hinweg vergleichen (Netzwerkspeicher, lokales NVMe, ein RAID während des Rebuilds), als gälte für alle derselbe Schwellenwert.
• Vergessen, dass die erste Zeile nach dem Start von iostat ein Durchschnitt seit dem Systemstart ist und nicht den aktuellen Zustand zeigt.