So überprüfen Sie die Festplatten-E / A-Auslastung pro Prozess

Ich habe ein Problem mit einem ins Stocken geratenen Linux-System, und ich habe festgestellt, dass sysstat / sar enorme Spitzen in der Festplatten-E / A-Auslastung, der durchschnittlichen Servicezeit sowie der durchschnittlichen Wartezeit zum Zeitpunkt des Systemstalls meldet.

Wie kann ich feststellen, welcher Prozess diese Spitzen beim nächsten Mal verursacht?
Kann man das mit sar machen (dh kann ich diese Informationen aus den bereits aufgenommenen sar-Dateien finden?

Die Ausgabe für "sar -d" erfolgte gegen 12.58-13.01 Uhr.

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

Dies ist eine Folgefrage zu einem Thread, den ich gestern gestartet habe: Plötzliche Lastspitzen und Wartezeiten auf Festplattenblöcke . Ich hoffe, dass ich ein neues Thema / eine neue Frage zu diesem Thema erstellt habe, da ich das Problem noch nicht lösen konnte.

Wenn Sie das Glück haben, die nächste Spitzenauslastungsperiode zu erreichen, können Sie die prozessbezogenen E / A-Statistiken mithilfe von iotop interaktiv untersuchen .

Sie können pidstat verwenden , um alle 20 Sekunden kumulative io-Statistiken pro Prozess zu drucken.

# pidstat -dl 20

Jede Zeile hat folgende Spalten:

• PID - Prozess-ID
• kB_rd / s - Anzahl der Kilobyte, die der Task pro Sekunde zum Lesen von der Festplatte veranlasst hat.
• kB_wr / s - Anzahl der Kilobyte, die die Task verursacht hat oder die pro Sekunde auf die Festplatte geschrieben werden soll.
• kB_ccwr / s - Anzahl der Kilobyte, deren Schreiben auf die Festplatte von der Task abgebrochen wurde. Dies kann auftreten, wenn der Task einen fehlerhaften Pagecache abschneidet. In diesem Fall werden einige E / A-Vorgänge, für die eine andere Aufgabe berücksichtigt wurde, nicht ausgeführt.
• Befehl - Der Befehlsname der Aufgabe.

Die Ausgabe sieht folgendermaßen aus:

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              

Nichts ist besser als die laufende Überwachung, Sie können einfach keine zeitkritischen Daten nach dem Ereignis zurückerhalten ...

Es gibt ein paar Dinge, die Sie möglicherweise überprüfen können, um sie zu implizieren oder zu eliminieren - /procist Ihr Freund.

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

Die Felder 10, 11 sind akkumulierte geschriebene Sektoren und akkumuliertes Zeitschreiben (ms). Daraufhin werden Ihre aktuellen Dateisystempartitionen angezeigt.

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

Diese Felder sind PID-, Befehls- und kumulative IO-Wait-Ticks. Dadurch werden Ihre aktuellen Prozesse angezeigt, allerdings nur, wenn sie noch ausgeführt werden . (Sie möchten wahrscheinlich die Journalling-Threads Ihres Dateisystems ignorieren.)

Der Nutzen der oben genannten Funktionen hängt von der Betriebszeit, der Art Ihrer lang laufenden Prozesse und der Verwendung Ihrer Dateisysteme ab.

Vorsichtsmaßnahmen: Gilt nicht für Kernel vor 2.6. Überprüfen Sie Ihre Dokumentation, wenn Sie sich nicht sicher sind.

(Jetzt geh und tu deiner Zukunft selbst einen Gefallen, installiere Munin / Nagios / Cacti / was auch immer ;-)

Verwenden Sie atop. ( http://www.atoptool.nl/ )

Schreiben Sie die Daten in eine komprimierte Datei, atopdie später in einem interaktiven Stil gelesen werden kann. Nehmen Sie alle 10 Sekunden eine Messung (Delta) vor. Mache es 1080 mal (3 Stunden; wenn du es vergisst, wird dir die Ausgabedatei nicht die Festplatte ausgehen):

$ atop -a -w historical_everything.atop 10 1080 &

Nach einer schlechten Sache passiert wieder:

(Auch wenn es noch im Hintergrund läuft, wird es nur alle 10 Sekunden angehängt.)

% atop -r historical_everything.atop

Da Sie IO gesagt haben, würde ich 3 Tasten drücken: tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display

Verwenden Sie btrace. Es ist zum Beispiel einfach zu bedienen btrace /dev/sda. Wenn der Befehl nicht verfügbar ist, ist er wahrscheinlich im Paket blktrace verfügbar .

BEARBEITEN : Da das debugfs im Kernel nicht aktiviert ist, könnten Sie versuchen, date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfoder ähnliches. Das Aufzeichnen von Seitenfehlern ist natürlich nicht dasselbe wie das Verwenden von btrace, aber wenn Sie Glück haben, können Sie damit Hinweise auf die am stärksten belasteten Prozesse erhalten. Ich habe gerade versucht, dass einer meiner Server mit der höchsten E / A-Intensität und eine Liste der Prozesse enthält, von denen ich weiß, dass sie viel E / A verbrauchen.