☰

Messen Sie die Festplatten-E/A-Latenzen eines laufenden Prozesses

tag-icon • tag-icon linux strace perf-event dtrace
Messen Sie die Festplatten-E/A-Latenzen eines laufenden Prozesses

Ich versuche, die Festplatten-E/A-Latenzen eines laufenden Prozesses zu messen, um ein Histogramm zu erstellen.

Ich könnte dies mit DTrace in Betriebssystemen tun, die es bereitstellen (z. B. wie indieses Joyent-Papier), aber meine Anwendung läuft unter Linux. Mein erster Gedanke war, es mit zu versuchen perf, und ich kann Zähler abrufen, aber ich kann keine Möglichkeit finden, Zeitdeltas abzurufen. Ich kann Zeitdeltas mit strace(z. B. strace -e read -T) abrufen, aber ich bin nicht sicher, ob ich die Ablaufverfolgung auf Festplatten-E/A beschränken kann (dieses System hat auch eine ausgelastete Netzwerkschnittstelle).

Gibt es eine Möglichkeit, dies unter Linux zu tun?

Antwort1

Das ist eigentlich kompliziert. Aber es gibt Hinweise:

  • Informieren Sie sich über SystemTap, das ist das Linux-Äquivalent zu DTrace. Ich glaube, sie haben vielleicht sogar Beispielskripts für ähnliche Aufgaben.

  • Lernenschwarzspur. Theoretisch können Sie die Ausgabe analysieren. Dies wird mehr Gerätelatenz (Servicezeit) bedeuten alsReaktionszeitProgramm weitermachen read().

Ja, straceist möglicherweise nicht geeignet, da es alles verfolgt (alle Systemaufrufe, auch wenn Sie -eeinen Filter verwenden) und den Server und den Prozess erheblich belastet. Perfist ein sehr obskures Tool, Sie denken vielleicht, Sie verstehen seine Ausgabe, aber das haben Sie eigentlich nicht, und sein Funktionsumfang hängt stark von der Kernelversion ab. Grundsätzlich und derzeit perfgeeignet zum MessenCPU-Zeit(Zyklen) und [noch] ungeeignet zur MessungReaktionszeiten(was Sie tatsächlich brauchen). Ich habe gehört, sie wollten etwas implementieren, um das zu erleichtern, also könnte es auf den neuesten Entwicklungskerneln etwas geben. (Schauen Sie auch in perf-scripts ( perf script -l) nach, wenn Sie weiter nachforschen möchten.)

  • Vielleicht können Sie etwas bekommen vonftrace. Lesen Sie diesen Artikelhttp://lwn.net/Articles/370423/(Und dies für dieEinleitung.) Wie ich sehe, können Sie ftracing durch pideine Funktion einschränken und dann mit etwas wie verfolgen sys_read. Ich habe dies als Beispiel für Sie ausprobiert:

    # mount -t debugfs debugfs /sys/kernel/debug # if it's not already mounted
# cd /sys/kernel/debug/tracing
# echo $$ > set_ftrace_pid  # pid of process to trace
# echo sys_read sys_write > set_ftrace_filter
# echo function_graph > current_tracer
# head trace

# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 0)   8.235 us    |  sys_write();
 0)   3.393 us    |  sys_write();
 0) ! 459859.3 us |  sys_read();
 0)   6.289 us    |  sys_write();
 0)   8.773 us    |  sys_write();
 0) ! 1576469 us |  sys_read();

Antwort2

Wenn Sie nur an der Anzahl der Lese- oder Schreibaufrufe an Blockgeräte interessiert sindDies ist Red Hats SOP zur Feststellung, dass.

Mithilfe der Block-Dump-Funktion und ein wenig Skripting können Sie sich einen umfassenden Überblick über die von Prozessen erzeugten E/A-Aktionen verschaffen. Führen Sie dazu die folgenden Schritte aus:

Deaktivieren Sie die Systemprotokollierung für einen kurzen Zeitraum (damit sie die Datenerfassung nicht behindert):

# Dienst Syslog stoppen # echo 1 > /proc/sys/vm/block_dump

Warten Sie, bis das Problem mit dem hohen Iowait auftritt. Aktivieren Sie anschließend Syslog (oder rsyslog, falls Sie dies verwenden) erneut und deaktivieren Sie den Block-Dump:

# Dienst Syslog starten # echo 0 > /proc/sys/vm/block_dump

Analysieren Sie mit dem folgenden Befehl die dmesg-Ausgabe auf Lese-/Schreib-/Dirtiated-Aktionen, die von bestimmten Prozessen ausgegeben werden:

# dmesg | awk '/(LESEN|SCHREIBEN|verschmutzt)/ {Aktivität[$1]++} END {für (x in Aktivität) drucke x, Aktivität[x]}'| sort -nr -k 2,2| head -n 10

kjournald(1425): 5984 kjournald(3681): 1269 pdflush(27301): 725 iostat(2913): 134 crond(26919): 61 crond(28985): 60 crond(7026): 54 sshd(28175): 50 sshd(15388): 50 nautilus(24498): 46

Die obige Beispielausgabe zeigt die 10 wichtigsten Prozesse, die während der Ausführung des Blockdumps Lese-, Schreib- und Dirty-Operationen ausgeführt haben. Mithilfe dieser Daten lässt sich ein Überblick über die Anzahl der von Prozessen ausgeführten Operationen gewinnen und feststellen, ob ein einzelner Prozess stark zu iowait beiträgt.

Es gibt außerdem mehrere Befehlszeilentools wie atop und iotop, die Ihnen Iowait-Statistiken pro Prozess liefern und als Teil eines Skripts ausgeführt werden können (d. h. sie verfügen über Batchmodi, die eine einzelne Iteration für bestimmte PIDs durchführen können).

BEARBEITEN: Wenn Sie mehr recherchieren, sieht es so aus, als ob SieHolen Sie sich iowait pro Prozess aus /proc/$pid/stat(Suche nach „Aggregierte Block-E/A-Verzögerungen“)

verwandte Informationen