Systemaufrufe mit strace -c nach Zeit zusammenfassen, Overhead und perf trace als Alternative

Ziel

Eine sortierte Zusammenfassung erhalten, in welchen Systemaufrufen ein Prozess Zeit verbringt, statt eines durchlaufenden Live-Traces, und erkennen, wann das Tracing selbst zum Engpass wird.

Voraussetzungen

Das Paket strace. Das Tracen eines selbst gestarteten Befehls (strace -c <command>) erfordert keine zusätzlichen Rechte. Das Anhängen an einen laufenden Prozess mit -p erfordert root oder CAP_SYS_PTRACE, ausser die Yama-Einstellung kernel.yama.ptrace_scope erlaubt es (beim üblichen Wert 1 darf ein unprivilegierter Benutzer nur an seine eigenen Nachkommen-Prozesse anhängen). perf, falls die Alternative aus Schritt 4 benötigt wird.

Schritte

1. Für eine begrenzte Zeit anhängen und danach wieder lösen, zum Beispiel mit timeout 20 strace -c -f -p <pid>. Ohne -f hängt -p nur an den einen Thread an, dessen ID <pid> ist, und übersieht damit die Worker-Threads eines Multithread-Servers. Laut strace-Manual zählt -c/--summary-only Zeit, Aufrufe und Fehler für jeden Systemaufruf und gibt beim Beenden eine Zusammenfassung aus, wobei die reguläre Ausgabe pro Aufruf unterdrückt wird. Das ist die aggregierte Sicht, die man für die Frage «Welcher Syscall dominiert?» braucht. Das Manual weist ausserdem darauf hin, dass dabei die Systemzeit (CPU-Zeit im Kernel) angezeigt wird, unabhängig von der Wanduhrzeit.
2. Die Zusammenfassung zunächst nach Zeitanteil in Prozent sortiert lesen. Da das Standardmass die CPU-Zeit im Kernel ist, erscheinen Aufrufe, die überwiegend blockieren (futex, epoll_wait, ein read auf einem Socket), darin als günstig. Geht es darum, wo der Prozess wartet, mit -w/--summary-wall-clock die Aufrufe nach Wanduhrzeit von Eintritt bis Rückkehr ordnen. Viel Zeit in futex oder epoll_wait deutet dann auf Contention oder Leerlaufwarten hin, viel Zeit in read/write auf I/O.
3. Die Kosten kennen, bevor man den Zahlen traut: Das strace-Manual hält ausdrücklich fest, dass ein getraceter Prozess langsamer läuft als ein nicht getraceter, und dass sich die Leistungseinbusse mit der Option --seccomp-bpf verringern lässt. Diese Option wirkt jedoch nur zusammen mit -f, ist für mit -p angehängte Prozesse nicht anwendbar und spart Unterbrechungen nur, wenn eine Teilmenge der Aufrufe getraced wird (-e trace=...). Beim oben beschriebenen Anhängen und Zählen hilft sie daher nicht. Bei einem latenzempfindlichen Prozess kann dieser Overhead das beobachtete Verhalten selbst verändern.
4. Wenn der Overhead eine Rolle spielt, stattdessen perf trace verwenden. Das Manual stellt es als von strace inspiriertes Werkzeug vor, das dieselbe Art von Syscall- und Systemereignis-Aktivität meldet, live oder aus einer zuvor aufgezeichneten perf record-Sitzung, und das auf der Tracepoint-/perf_events-Infrastruktur des Kernels statt auf ptrace aufbaut. Für eine Live-Ansicht perf trace -p <pid> ausprobieren, für eine Zusammenfassung pro Thread mit minimaler, durchschnittlicher und maximaler Zeit perf trace -s -p <pid>; normalerweise sind dafür root-Rechte nötig.
5. Keinen festen prozentualen Unterschied zwischen beiden Werkzeugen annehmen, ohne am tatsächlichen Workload zu messen. Keines der beiden Manuals nennt eine Zahl für den Overhead, und die relativen Kosten hängen davon ab, wie syscall-lastig der Workload ist.

Erwartetes Ergebnis

Eine sortierte Liste, welche Systemaufrufe am meisten Zeit verbraucht haben und wie oft sie aufgerufen wurden, gewonnen ohne vollständigen Trace Zeile für Zeile. Dazu eine fundierte Wahl zwischen der Einfachheit von strace -c und dem anderen Overhead-Profil von perf trace.

Grenzen und Prüfbasis

Beide Werkzeuge sehen nur die Aktivität nach dem Anhängen; ein früherer Ausschlag bleibt unbemerkt. -f/--follow-forks ist nötig, um auch die Aufrufe von Kindprozessen und, zusammen mit -p, der übrigen Threads mitzuzählen. Nach dem Erfassen der Zusammenfassung zügig lösen, da der Overhead während der gesamten Dauer des Anhängens anfällt und nicht nur, solange die Ausgabe gelesen wird.