CPU und I/O pro Prozess mit pidstat und /proc/<pid>/io: die Ursache von I/O-Wait finden

Ziel

Den einen Prozess identifizieren, der für CPU-Last oder Disk-I/O verantwortlich ist, die systemweite Werkzeuge (top, iostat) nur aggregiert anzeigen können.

Voraussetzungen

Das Paket sysstat für pidstat; Lesezugriff auf /proc/<pid>/io des Zielprozesses. Diesen regelt der Kernel über eine ptrace-Leseberechtigungsprüfung (in der Praxis der Benutzer des Prozesses selbst oder root bei Prozessen anderer Benutzer). Auch pidstat -d zeigt Tasks anderer Benutzer nur an, wenn es als root läuft.

Schritte

1. Zuerst die CPU-Last pro Prozess betrachten: pidstat 1 5 listet die CPU-Anteile pro Task in Prozent auf. Laut Handbuch von sysstat meldet pidstat Statistiken zu einzelnen Tasks, die der Kernel gerade verwaltet, sodass kein Namensfilter auf die Ausgabe von top nötig ist.
2. Speicher und Kontextwechsel im selben Durchlauf erfassen: pidstat -r -w 1 5 (-r für Speicher, -w für Kontextwechsel). Das hilft, wenn die CPU allein die Last nicht erklärt.
3. Danach das Disk-I/O pro Prozess prüfen: pidstat -d 1 5 meldet pro Task die gelesenen und geschriebenen Kilobytes pro Sekunde sowie die I/O-Verzögerung (iodelay). iodelay beruht auf dem Delay Accounting des Kernels, das seit Linux 5.14 standardmässig deaktiviert ist (aktivierbar mit sysctl kernel.task_delayacct=1 oder dem Boot-Parameter delayacct); ohne dieses bleibt die Spalte bei null.
4. Bei einer verdächtigen PID die Rohzähler direkt auslesen: cat /proc/<pid>/io. proc_pid_io(5) beschreibt rchar/wchar als die Bytes, die erfolgreiche Aufrufe von read(2)/write(2) und ähnliche zurückgeben – das umfasst Treffer im Page Cache, Pipes, Sockets und Terminals. read_bytes/write_bytes sind die Bytes, die tatsächlich von der Speicherschicht geholt oder dorthin gesendet wurden; sie liegen näher an dem, was iostat am Gerät sieht. write_bytes wird angerechnet, sobald der Prozess Seiten im Page Cache verändert (dirty); der physische Schreibvorgang kann das Gerät also erst später beim Writeback erreichen.
5. /proc/<pid>/io zweimal in einem bekannten Abstand auslesen und die Werte subtrahieren, um eine Rate zu erhalten – so leitet auch pidstat -d seine Zahlen ab. Das funktioniert ebenfalls für Prozesse, die schon vor Beginn der Beobachtung gestartet wurden.
6. Zusammenhänge herstellen: Ein Prozess, dessen read_bytes/write_bytes genau in dem Zeitfenster wachsen, in dem iostat -xz ein ausgelastetes Gerät gezeigt hat, ist als Nächstes zu untersuchen, etwa anhand seiner offenen Dateien (ls -l /proc/<pid>/fd).

Erwartetes Ergebnis

Eine konkrete PID samt Kommandozeile, die für die systemweit beobachtete Last verantwortlich ist, in denselben Einheiten (KB/s), die die Werkzeuge auf Geräteebene bereits gemeldet haben.

Grenzen und Prüfbasis

rchar/wchar zählen logisches I/O inklusive Cache-Treffern und I/O ohne Dateibezug und können daher weit über dem physischen Datenverkehr am Gerät liegen. Geht es darum, wie viel Arbeit der Prozess der Disk tatsächlich aufgebürdet hat, sind read_bytes/write_bytes heranzuziehen. Sowohl pidstat als auch das Lesen von /proc/<pid>/io sind rein lesende Beobachtungen, bei denen nichts rückgängig zu machen ist; ein Prozess, der zwischen zwei Messungen endet, fehlt in der nächsten Messung schlicht.