it-swarm.com.de

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

Ich habe ein Problem mit einem blockierenden Linux-System und ich habe festgestellt, dass sysstat/sar große Spitzen in der Festplatten-E/A-Auslastung, der durchschnittlichen Servicezeit sowie der durchschnittlichen Wartezeit zum Zeitpunkt des Systemstillstands meldet.

Wie kann ich feststellen, welcher Prozess diese Spitzen beim nächsten Mal verursacht?
Ist es möglich, mit sar zu tun (dh: kann ich diese Informationen aus den bereits aufgezeichneten sar-Dateien finden?

Die Ausgabe für "sar -d" erfolgte zwischen 12.58 und 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 Spitzen beim Laden und Warten auf den Festplattenblock , ich hoffe, es ist in Ordnung, dass ich ein neues Thema erstellt habe/Frage zu diesem Thema, da ich das Problem noch nicht lösen konnte.

48
Avada Kedavra

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.

50
halp

Mit pidstat können Sie mit diesem Befehl alle 20 Sekunden kumulative io-Statistiken pro Prozess drucken:

# pidstat -dl 20

Jede Zeile enthält folgende Spalten:

  • PID - Prozess-ID
  • kB_rd/s - Anzahl der Kilobyte, die die Task pro Sekunde von der Festplatte gelesen hat.
  • kB_wr/s - Anzahl der Kilobyte, die die Aufgabe 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 die Aufgabe einen verschmutzten Seitencache abschneidet. In diesem Fall werden einige IO, 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]              
31
user920391

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

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

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

Die Felder 10, 11 sind akkumulierte geschriebene Sektoren und akkumulierte Zeit (ms) beim Schreiben. Dies zeigt Ihre heißen Dateisystempartitionen an.

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

Diese Felder sind PID-, Befehls- und kumulative IO-Wait-Ticks. Dies zeigt Ihre heißen Prozesse an, allerdings nur wenn sie noch laufen. (Sie möchten wahrscheinlich die Journalling-Threads Ihres Dateisystems ignorieren.)

Der Nutzen der oben genannten Punkte hängt von der Verfügbarkeit, 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 einen Gefallen, installiere Munin/Nagios/Cacti/was auch immer ;-)

12
mr.spuratic

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

Schreiben Sie die Daten in eine komprimierte Datei, die atop später in einem interaktiven Stil lesen kann. Nehmen Sie alle 10 Sekunden eine Messung (Delta) vor. Mach 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 &

Nachdem wieder etwas Schlimmes passiert:

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

% atop -r historical_everything.atop

Da Sie IO sagten, 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
11
Wayne Walker

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

EDIT : Da das Debugfs im Kernel nicht aktiviert ist, können Sie date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf o.ä. Das Protokollieren von Seitenfehlern ist natürlich keineswegs dasselbe wie das Verwenden von btrace, aber wenn Sie Glück haben, kann es Ihnen einen Hinweis auf die am meisten festplattenhungrigen Prozesse geben. Ich habe gerade versucht, dass einer meiner E/A-intensivsten Server und die Liste die Prozesse enthält, von denen ich weiß, dass sie viel E/A verbrauchen.

5