strace und perf zur Fehlerbehebung unter Linux

Wenn ein Linux-Server langsam ist, abstürzt oder die CPU überlastet und die Anwendungsprotokolle keine Erklärung liefern, decken zwei Tools den Großteil der Lücke ab. strace zeigt Ihnen, was ein Prozess vom Kernel anfordert. perf zeigt Ihnen, womit die CPU ihre Zeit verbringt. Zusammen beantworten sie die Fragen „Warum hängt es?“ und „Was macht es gerade?“, was sonst nichts so kostengünstig schafft.

Dieser Beitrag behandelt, wann man welches Tool einsetzen sollte, wie man sie installiert, welche Befehle man tatsächlich ausführt und wie man den Overhead auf einem Live-Server überschaubar hält.

Wann sollte man strace und wann perf verwenden?

Die Unterscheidung ist einfach. Verwenden Sie perf , wenn die CPU ausgelastet ist und Sie wissen müssen, welche Funktion dafür verantwortlich ist. Verwenden Sie strace , wenn ein Prozess hängt, abstürzt, seltsame Fehler zurückgibt oder sich auf eine Weise verhält, die die Logs nicht erklären.

perf liest die Hardware-Zähler des Kernels mit einer konfigurierbaren Frequenz aus, sodass der Overhead in der Regel unter 1 % liegt und der Einsatz in der Produktion sicher ist. strace fängt jeden Systemaufruf über ptrace, was den Zielprozess um das 10- bis 100-fache verlangsamen kann. Setze es auf Live-Systemen sparsam ein und immer mit Filtern.

Installation von strace und perf

Beide Tools befinden sich in den Standard-Repositories. strace basiert auf dem ptrace Syscall, der seit Jahren Bestandteil jedes modernen Kernels ist. perf nutzt die perf_events Schnittstelle und benötigt ein Paket, das zu Ihrem laufenden Kernel passt.

Unter Ubuntu oder Debian:

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

Unter RHEL, AlmaLinux oder Fedora:

sudo dnf install strace perf

Das $(uname -r) Bit ist entscheidend. Eine perf-Binärdatei, die für eine andere Kernel-Version kompiliert wurde, erzeugt verwirrende Ausgaben und kann Ereignisse unbemerkt auslassen. Überprüfen Sie dies mit perf --version und strace -V nach der Installation.

Damit perf Funktionsnamen anstelle von Hex-Adressen anzeigt, benötigen Sie Debug-Symbole. Installieren Sie die entsprechenden -dbg oder -debuginfo Paket (zum Beispiel libc6-dbg unter Debian) und kompilieren Sie Ihre eigenen Binärdateien mit -g in GCC.

In Containern strace benötigt --cap-add=SYS_PTRACE und perf benötigt --cap-add=SYS_ADMIN beim Starten mit Docker. Ohne diese Einschränkungen versagen die Tools auf eine Weise, die wie Fehler aussieht.

Verfolgen von Systemaufrufen mit strace

Mit strace command verfolgt einen Prozess ab dem Start. Um sich an einen laufenden Prozess anzuhängen, verwenden Sie strace -p PID. Bei Multithread-Prozessen oder solchen, die Forks erzeugen, fügen Sie -f hinzu, um die untergeordneten Prozesse zu verfolgen, da Sie sonst den Großteil der Aktivitäten verpassen.

Die Ausgabezeilen enden mit einem Rückgabewert. -1 ENOENT bedeutet, dass die vom Prozess angeforderte Datei nicht vorhanden ist. -1 EACCES bedeutet, dass es sich um Berechtigungsprobleme handelt. Diese beiden Fehler machen allein einen überraschend großen Anteil der Produktionsfehler aus.

Das nützlichste Flag ist -e trace=GROUP, das die Ausgabe auf eine bestimmte Kategorie von Systemaufrufen beschränkt und den Datenfluss überschaubar hält.

Auf einem stark ausgelasteten Server strace -c -p PID für zehn oder zwanzig Sekunden. Das -c Flag gibt beim Trennen eine Zusammenfassung der Systemaufrufzahlen, der Gesamtzeit und der Fehler aus. So erkennen Sie, welche Kategorie eine genauere Untersuchung wert ist, ohne das Terminal zu überfluten. Verbinden Sie sich anschließend mit einem schmalen Filter erneut.

Weitere nützliche Flags: -T protokolliert die für jeden Aufruf aufgewendete Zeit, -Z zeigt nur fehlgeschlagene Aufrufe an und -o file schreibt in ein Protokoll statt auf das Terminal, was bei einem lautstarken Prozess deutlich schneller ist.

CPU-Profiling mit perf

perf verfügt über vier Befehle, die Sie am häufigsten verwenden werden.

Beginnen Sie mit perf stat -p PID für einen schnellen Überblick. Die zu beachtenden Zahlen:

• IPC (Befehle pro Takt) unter 1,0: Die CPU kommt ins Stocken, meist beim Speicherzugriff.
• Hohe Anzahl von LLC-Load-Misses: Der Arbeitsspeicher passt nicht in den Cache, sodass die CPU auf den RAM wartet.
• Hohe Anzahl an Kontextwechseln: typisch für I/O-gebundene Workloads, bei denen Threads ständig auf Festplatte oder Netzwerk warten.

Wenn etwas nicht stimmt, gehen Sie mit perf record -F 99 -g -p PID -- sleep 30. Die -F 99 erfasst mit 99 Hz, was ausreicht, um Hot-Funktionen zu finden, und eine Synchronisation mit dem Kernel-Timer bei runden Zahlen wie 100 Hz vermeidet. Das -g Flag erfasst Aufrufgraphen, sodass perf report Ihnen zeigen kann, welche Pfade in eine Funktion hinein dafür verantwortlich sind.

In perf reportDie Spalte „Overhead“ gibt den Anteil an den gesamten Samples an. Ein hoher Overhead in _int_malloc oder memcpy bedeutet eine intensive Speicherzuweisung. Ein hoher Overhead in einer Ihrer eigenen Funktionen ist der Hotspot, nach dem Sie gesucht haben.

Wenn Sie Hex-Adressen anstelle von Funktionsnamen sehen, ist die Binärdatei gestrippt oder es fehlen Debug-Symbole. Installieren Sie das passende -dbg Paket oder erstellen Sie die Binärdatei neu mit -g.

Ein praktischer Arbeitsablauf auf einem Live-Server

Bei einem echten Vorfall auf einem stark ausgelasteten Server sieht die Vorgehensweise wie folgt aus:

1. Überprüfen Sie das Symptom zunächst mit einfachen Tools: top, vmstat, iostat. Wenn Sie auf einer VM arbeiten, überprüfen Sie die st Spalte „(steal)“. Alles über 5 % bedeutet, dass der Hypervisor der Engpass ist, nicht Ihr Code.
2. Wenn die CPU-Auslastung hoch ist, führe perf top einige Sekunden lang aus und führen Sie dann perf record -F 99 -g -p PID -- sleep 30 für den betreffenden Prozess. Eine 30-sekündige Erfassung bei 99 Hz erzeugt etwa 1,7 MB Daten.
3. Wenn der Prozess hängt, langsam ist oder Fehler zurückgibt, führen Sie strace -c -p PID für zehn Sekunden aus und lesen Sie die Zusammenfassung. Wenn eine Syscall-Kategorie dominiert, grenzen Sie die Suche mit strace -e trace=GROUP -T -p PID.
4. Wenn Sie den verdächtigen Systemaufruf oder die verdächtige Funktion gefunden haben, trennen Sie die Verbindung. Lassen Sie keines der beiden Tools länger als nötig in der Produktionsumgebung laufen.

Zwei Hinweise. strace Die Ausgabe kann Umgebungsvariablen, Dateipfade und aus Sockets gelesene Bytes enthalten; bereinigen Sie daher die Protokolle, bevor Sie sie außerhalb Ihres Teams weitergeben. Und wenn Sie dies regelmäßig tun möchten, sehen Sie sich bpftrace und das umfassendere eBPF-Toolkit als nächsten Schritt an: gleiche Transparenz, weniger als 1 % Overhead, von Anfang an für die Produktion konzipiert.

Wenn Sie Workloads ausführen, bei denen ein tiefer diagnostischer Zugriff wichtig ist und eine gemeinsam genutzte Infrastruktur keine Option ist, sehen Sie sich unsere dedizierten Server an.