iostat und iotop: Diagnose von Speicherengpässen unter Linux

Wenn ein Linux-Server langsam erscheint, ist der Speicher einer der ersten Bereiche, die man überprüfen sollte. iostat zeigt Ihnen, ob die Festplatte überlastet ist; iotop zeigt Ihnen, welcher Prozess die Auslastung verursacht. Zusammen beantworten sie die beiden entscheidenden Fragen: Ist die Festplatte tatsächlich der Engpass, und wenn ja, was belastet sie? Dieser Beitrag behandelt die Installation, das Lesen der Ausgabe (einschließlich der Frage, wo die %util Metrik auf moderner Hardware liegt) sowie einen Arbeitsablauf, um vom Symptom zur Lösung zu gelangen.

Installation von iostat und iotop

iostat ist im sysstat-Paket enthalten; iotop wird separat ausgeliefert. Installieren Sie beide:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

Unter Ubuntu ist sysstat deaktiviert. Um Hintergrunddaten für eine spätere Analyse mit sar, bearbeiten Sie /etc/default/sysstat, setzen Sie ENABLED="true"und starten Sie den Dienst neu:

sudo systemctl restart sysstat

iotop muss als root ausgeführt werden. Unter RHEL 9 und neuer ist die Verzögerungserfassung standardmäßig deaktiviert, wodurch die IO und SWAPIN Spalten leer bleiben. Aktivieren Sie es mit:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Fügen Sie kernel.task_delayacct = 1 zu /etc/sysctl.conf hinzu, damit die Einstellung auch nach einem Neustart erhalten bleibt.

Auswertung der iostat-Ausgabe

Führen Sie iostat mit erweiterten Statistiken aus und ignorieren Sie die erste Stichprobe, die nur Durchschnittswerte seit dem Systemstart anzeigt:

iostat -xz 2

Das -x Flag fügt erweiterte Statistiken hinzu, -z blendet inaktive Geräte aus und die 2 aktualisiert alle zwei Sekunden. Die wichtigen Spalten:

• await: durchschnittliche Zeit in Millisekunden, die eine E/A-Anforderung benötigt, einschließlich der Wartezeit in der Warteschlange. Die wichtigste Zahl, wenn sich Benutzer über Langsamkeit beschweren.
• r/s sowie w/s: Lese- und Schreib-IOPS. In Kombination mit rkB/s und wkB/s geben diese Werte Aufschluss darüber, ob Ihre Arbeitslast zufällig (hohe IOPS, geringer Durchsatz) oder sequenziell (niedrige IOPS, hoher Durchsatz) ist.
• aqu-sz: durchschnittliche Warteschlangentiefe. Bei HDDs bedeutet ein Wert, der dauerhaft über 1 liegt, dass die Festplatte nicht mithalten kann.
• %util: Prozentsatz der Zeit, in der das Gerät mindestens einen laufenden I/O-Vorgang hatte. Nützlich bei HDDs, irreführend bei NVMe (siehe unten).

Eine kurze Übersicht über Schwellenwerte:

Wo %util liegt

%util , ist die Kennzahl, auf die die meisten Leute zuerst zurückgreifen, und bei NVMe ist sie aktiv irreführend. Der Kernel zählt %util „jede zu einem beliebigen Zeitpunkt laufende E/A“-Operation mit, was für eine rotierende Festplatte, die jeweils nur eine Anfrage verarbeitet, in Ordnung ist, für NVMe-Geräte jedoch bedeutungslos ist, die Tausende von Anfragen parallel über Hardware-Warteschlangen hinweg bearbeiten. Ein NVMe-Laufwerk kann bei 100 % %util , während es nur mit 5 % seiner tatsächlichen Kapazität arbeitet.

Vertrauen Sie bei NVMe r_await, w_awaitund aqu-sz stattdessen. Wenn r_await unter 1 ms bleibt und die Warteschlangentiefe deutlich unter der Hardware-Warteschlangentiefe des Geräts liegt (oft 1024 oder höher), ist das Laufwerk tatsächlich nicht ausgelastet, unabhängig davon, was %util angezeigt wird.

Für eine schnelle NVMe-Anzeige in MB/s statt in kB/s:

iostat -xm 1

Für eine Langzeiterfassung können Sie später eine Korrelation mit Anwendungsprotokollen herstellen:

iostat -x -t 5 720 > /var/log/iostat.log

Das liefert eine Stunde lang alle 5 Sekunden eine Stichprobe. sar Aus demselben sysstat-Paket erhalten Sie die entsprechenden Daten mit persistenter historischer Speicherung, was die bessere Wahl für die fortlaufende Überwachung darstellt.

Bestätigung mit CPU-Iowait

Wenn iostat Speicherauslastung anzeigt, überprüfen Sie dies anhand der %iowait Spalte in der CPU-Zusammenfassung oben in derselben Ausgabe ab. Anhaltende %iowait Werte über 15–20 % in Verbindung mit hohen await bestätigt, dass der Engpass beim Speicher liegt. Wenn %iowait hoch ist, await normal aussieht, führen Sie vmstat 1 und überprüfen Sie die si und so . Eine Swap-Aktivität ungleich Null bedeutet, dass Sie speichergebunden sind und der Festplattenverkehr aus Paging resultiert, nicht aus Anwendungs-I/O.

Auswertung der iotop-Ausgabe

Sobald iostat einen Speicherengpass bestätigt, zeigt iotop an, welcher Prozess dafür verantwortlich ist. Beginnen Sie mit:

sudo iotop -o

Das -o Flag blendet inaktive Prozesse aus, sodass nur diejenigen angezeigt werden, die aktiv E/A-Vorgänge ausführen. Die zu beachtenden Spalten:

• DISK READ / DISK WRITE: Echtzeit-Durchsatz pro Prozess. Identifiziert die offensichtlichen „Schwergewichte“.
• IO: Prozentsatz der Zeit, in der der Prozess durch E/A blockiert ist. Ein Prozess, der nur 50 kB/s schreibt, kann 99 % IO anzeigen, wenn er winzige synchrone fsync() . Diese Spalte ist wichtiger als der reine Durchsatz.
• SWAPIN: Prozentsatz der Zeit, die auf Swap-Seiten gewartet wird. Ein Wert ungleich Null bedeutet hier, dass das System paged und Ihr „Speicherproblem“ in Wirklichkeit ein Speicherproblem ist.

Bei Multithread-Anwendungen (MySQL, PostgreSQL, Java-Workloads) fassen Sie die Threads mit -Pund addieren -a hinzu, um die Gesamtwerte seit dem Start von iotop zu akkumulieren:

sudo iotop -oPa

Das -a Flag ist der Trick, um spitzenlastige Workloads wie Backup-Jobs zu erfassen, die jeweils nur wenige Sekunden laufen und in einer Live-Ansicht sonst schwer zu erkennen wären.

Für die unbeaufsichtigte Protokollierung während nächtlicher Zeitfenster, wenn niemand zusieht:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Dadurch wird alle 10 Sekunden ein nicht-interaktiver Snapshot geschrieben. Kombinieren Sie dies mit Zeitstempeln aus Ihren Backup- oder Cron-Jobs, um den Verursacher im Nachhinein zu finden.

Ein diagnostischer Arbeitsablauf

Die meisten Untersuchungen zur Festplatten-E/A folgen dem gleichen Ablauf:

1. iostat -xz 2 um zu bestätigen, dass die Festplatte tatsächlich der Engpass ist. Siehe await, aqu-szund %iowait. Wenn diese normal sind, liegt das Problem nicht beim Speicher, und Sie sollten ganz woanders suchen.
2. iotop -oPa um den Prozess zu finden, der die Last verursacht. Achten Sie mehr auf die IO-Spalte als auf die Durchsatz-Spalte. Die schlimmsten Übeltäter sind oft Programme, die viele kleine synchrone Schreibvorgänge ausführen, nicht diejenigen, die die meisten Bytes verschieben.
3. lsof -p <pid> um zu sehen, auf welche Dateien dieser Prozess zugreift. Dadurch lässt sich die Art der Arbeitslast meist sofort erkennen: ein Write-Ahead-Log einer Datenbank, eine Anwendungsprotokolldatei, ein Backup-Mountpunkt, eine temporäre Datei.

Zwei Muster, die man kennen sollte.

Wenn Sie Kernel-Threads wie jbd2/... (ext4-Journal) oder txg_sync (ZFS) ganz oben bei den Schreibern von iotop sehen, reagieren diese auf Schreibvorgänge anderer Prozesse und initiieren sie nicht selbst. Der User-Space-Prozess, der den Journal-Verkehr verursacht, ist die eigentliche Ursache; suchen Sie weiter.

Auf einem VPS await mit niedrig %util ist das klassische Anzeichen für einen „Noisy Neighbor“. Ein anderer Mandant monopolisiert den gemeinsam genutzten Speicher, und Ihre E/A-Vorgänge stehen auf der Hypervisor-Seite in der Warteschlange, nicht auf Ihrer virtuellen Festplatte. Sie können dies vom Gast aus bestätigen, aber nicht beheben; die Lösung besteht entweder darin, das Problem an den Anbieter zu eskalieren oder auf einen Server mit isoliertem Speicher umzuziehen.

Behebung häufiger I/O-Engpässe

Sobald Sie wissen, was die Festplatte belastet, sind die Lösungen in der Regel unkompliziert.

Entziehen Sie nicht kritischen I/O-Vorgängen die Priorität. ionice versetzt einen Prozess in die Idle-Scheduling-Klasse, wo er nur dann Festplattenbandbreite nutzt, wenn nichts anderes diese benötigt:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

Die erste Form ändert einen laufenden Prozess; die zweite startet einen neuen, der bereits in der Leerlaufklasse ist. In iotop können Sie die Priorität eines laufenden Prozesses interaktiv ändern, indem Sie i drücken.

Verlagern Sie rechenintensive Workloads auf schnelleren Speicher. Wenn iostat eine durch Datenbank-Schreibvorgänge überlastete SATA-Festplatte anzeigt und sich im selben Rechner ein ungenutzter NVMe-Speicher befindet, verlagern Sie das Datenbank-Datenverzeichnis. Der um Größenordnungen höhere IOPS-Wert macht dies zur wirksamsten verfügbaren Lösung.

Stellen Sie den richtigen I/O-Scheduler ein. Moderne Kernel verwenden standardmäßig vernünftige Einstellungen, aber es lohnt sich, dies zu überprüfen. Stellen Sie für NVMe und SSDs den Scheduler auf none. Das Gerät bewältigt die Warteschlangenverwaltung in der Hardware besser als der Kernel:

echo none > /sys/block/nvme0n1/queue/scheduler

Für HDDs mit gemischten Workloads mq-deadline ist die übliche Wahl.

Mounten Sie mit noatime. Standardmäßig aktualisiert jeder Lesevorgang den Zeitstempel des letzten Zugriffs auf die Datei, wodurch bei jedem Lesevorgang ein Schreibvorgang erzeugt wird. Bei leseintensiven Dateisystemen ist dies unnötige E/A. Fügen Sie noatime zu den Mount-Optionen in /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Passen Sie das Writeback für burstartige Schreibvorgänge an. Auf Servern mit reichlich RAM lassen die Standardschwellenwerte für Dirty-Pages den Seiten-Cache Gigabytes an ungeschriebenen Daten ansammeln, die dann in einem großen Durchlauf geleert werden. Senken Sie die Schwellenwerte in /etc/sysctl.conf , um dies zu glätten:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Die Festplatte selbst ist in der Regel nicht das Problem. Wenn iostat hohe IOPS und einen niedrigen Durchsatz anzeigt, führt die Workload zufällige E/A-Vorgänge an Daten durch, die sequenziell sein könnten, oder führt viele kleine Schreibvorgänge aus, die gebündelt werden könnten. Schauen Sie sich die Anwendung an, bevor Sie der Hardware die Schuld geben.

Wenn Sie speicherintensive Workloads auf einem Server ausführen, auf dem das Netzwerk die Festplatte überholen kann, bieten Ihnen die NVMe-gestützten dedizierten Server von FDC den Spielraum, die oben genannten Optimierungen produktiv anzuwenden.