Debuggen der Linux-I/O-Latenz

Jetzt habe ich es zu gegebener Zeit selbst gelöst, so dass ich es zumindest für die Nachwelt selbst nachverfolgen kann.

Leider habe ich das ursprüngliche Problem bei einem Kernel-Upgrade verloren, aber stattdessen ein neues bekommen, das noch schlechter in der Leistung und genauso schwer aufzuspüren ist. Die Techniken, die ich gefunden habe, waren die folgenden:

Zuerst einmal blktrace /blkparse ist ein Tool, das ich sehr hilfreich fand. Es ermöglicht die Verfolgung des Fortschritts einzelner I/O-Anforderungen mit vielen hilfreichen Details, z. B. dem Prozess, der die Anforderung gesendet hat. Es ist hilfreich, die Ausgabe auf tmpfs zu legen , damit die Handhabung der Speicherung des Traces nicht selbst mit dem Tracing beginnt.

Das hat jedoch nur so weit geholfen, also habe ich einen Kernel mit mehr Debugging-Funktionalität kompiliert. Insbesondere habe ich ftrace gefunden sehr hilfreich, da es mir ermöglichte, den schlecht funktionierenden Prozess im Kernel-Space zu verfolgen, um zu sehen, was er tat und wo er blockierte. Das Kompilieren eines Debug-Kernels liefert auch funktionierendes WCHAN Ausgabe für ps auch, was zumindest für einfachere Fälle als einfacherer Weg dienen kann, um zu sehen, was ein Prozess innerhalb des Kernels tut.

Ich hatte auch gehofft, dass LatencyTop nützlich sein würde, aber ich fand es ziemlich fehlerhaft und leider auch, dass es nur Latenzgründe anzeigte, die zu "high-level" waren, um wirklich nützlich zu sein.

Außerdem fand ich es hilfreicher als iostat um einfach den Inhalt von /sys/block/$DEVICE/stat anzuzeigen in sehr engen Abständen, einfach so:

while :; do cat /sys/block/sda/stat; sleep .1; done

Siehe Documentation/iostats.txt im Kernel-Quellbaum für das Format stat Datei. Indem ich es in engen Abständen betrachtete, konnte ich das genaue Timing und die Größe von I/O-Bursts und dergleichen sehen.

Am Ende fand ich heraus, dass das Problem, das ich nach dem Kernel-Upgrade hatte, durch Stable Pages verursacht wurde, eine Funktion, die in Linux 3.0 eingeführt wurde und in meinem Fall dazu führte, dass Berkeley DB für längere Zeit anhielt, wenn Seiten in seinem mmap'ed verschmutzt wurden Regionsdateien. Obwohl es möglich scheint, dieses Feature zu patchen und die dadurch verursachten Probleme in Linux 3.9 behoben werden könnten, habe ich das schlimmste Problem, das ich im Moment hatte, gelöst, indem ich Berkeley DB gepatcht habe, damit ich seine Regionsdateien in einem anderen Verzeichnis ablegen kann (in meinem Fall /dev/shm ), wodurch ich das Problem vollständig vermeiden konnte.

Meiner Erfahrung nach ist http://freecode.com/projects/sysstat alias http://freecode.com/projects/sysstat das einfachste und detaillierteste Statistiktool, das Sie installieren können, um mysteriöse Probleme mit der Systemleistung aufzuspüren. sar

Sicherlich möchten Sie sich auch die Ausgabe des iostat-Befehls ansehen, insbesondere wie viel Ihr %iowait unter 5-10% unter normaler Systemlast (unter 1,0 oder so) liegen sollte.

Schauen Sie sich die ps-Ausgabe an, wenn Sie in der STAT-Spalte D-Status sehen, was bedeutet, dass diese Prozesse gesperrt sind und auf IO warten, sehr wahrscheinlich ein Hardwareproblem mit dem Controller oder der Festplatte, überprüfen Sie S.M.A.R.T-Statistiken sowie dmesg und syslog auf Hinweise

Überprüfen Sie das sar-Protokoll und identifizieren Sie Spitzenzeiten, falls dies jemals passiert, und versuchen Sie, diese Zeit mit plattenintensiven Cron-Jobs abzugleichen, z. B. Sicherungen über das Netzwerk

Sie können Ihre Festplattenleistung mit bonnie++

messen

Ich dachte, ich würde strace erwähnen, obwohl diese Frage jetzt Monate alt ist. Es kann jemandem mit einem ähnlichen Problem helfen, der diese Seite findet.

versuchen.

strace "application"

Sie können auch tun

strace -e read,write "application"

um nur Lese-/Schreibereignisse anzuzeigen.

Die Anwendung wird normal geladen (wenn auch etwas langsamer zu starten) und Sie können sie wie gewohnt verwenden, um das Problem auszulösen. Die Ausgabe erscheint in der Shell, die Sie zum Starten von strace verwendet haben.

Das Gute an strace ist, dass Sie den letzten Funktions-/Kernel-Aufruf zu dem Zeitpunkt sehen können, zu dem die Anwendung die Verlangsamung auslöst. Möglicherweise finden Sie dies, wenn Ihr /home Konten auf NFS befinden, hat die Anwendung aus irgendeinem Grund Schwierigkeiten mit der Datei-E/A über NFS.