strace en perf voor het oplossen van problemen met Linux

Wanneer een Linux-server traag is, crasht of de CPU overbelast en de applicatielogboeken geen verklaring bieden, vullen twee tools het grootste deel van de leemte op. strace vertelt u wat een proces van de kernel vraagt. perf vertelt je waar de CPU zijn tijd aan besteedt. Samen beantwoorden ze de vragen "waarom loopt het vast" en "wat doet het", die niets anders zo goedkoop kan beantwoorden.

Dit bericht behandelt wanneer je welke tool moet gebruiken, hoe je ze installeert, de commando's die je daadwerkelijk uitvoert en hoe je de overhead op een live server beheersbaar houdt.

Wanneer strace en wanneer perf gebruiken

Het verschil is simpel. Gebruik perf wanneer de CPU bezet is en u wilt weten welke functie hiervoor verantwoordelijk is. Gebruik strace wanneer een proces vastloopt, crasht, vreemde fouten retourneert of zich gedraagt op een manier die de logs niet verklaren.

perf neemt met een instelbare frequentie monsters van de hardwaretellers van de kernel, dus de overhead is meestal minder dan 1% en het is veilig om in productie te draaien. strace onderschept elke systeemaanroep via ptrace, wat het doelproces 10 tot 100 keer kan vertragen. Gebruik het spaarzaam op live systemen, en altijd met filters.

Strace en perf installeren

Beide tools bevinden zich in de standaardrepositories. strace is afhankelijk van de ptrace syscall, die al jaren deel uitmaakt van elke moderne kernel. perf maakt gebruik van de perf_events en heeft een pakket nodig dat past bij de kernel die u gebruikt.

Op Ubuntu of Debian:

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

Op RHEL, AlmaLinux of Fedora:

sudo dnf install strace perf

De $(uname -r) bit is van belang. Een perf-binair bestand dat is gebouwd tegen een andere kernelversie produceert verwarrende uitvoer en kan stilletjes gebeurtenissen weglaten. Controleer dit met perf --version en strace -V na de installatie.

Om ervoor te zorgen dat perf functienamen weergeeft in plaats van hex-adressen, hebt u debug-symbolen nodig. Installeer de relevante -dbg of -debuginfo pakket (bijvoorbeeld libc6-dbg op Debian) en compileer je eigen binaire bestanden met -g in GCC.

Binnen containers strace is --cap-add=SYS_PTRACE en perf is nodig --cap-add=SYS_ADMIN bij het starten met Docker. Zonder deze caps mislukken de tools op manieren die op bugs lijken.

Systeemaanroepen traceren met strace

Het uitvoeren van strace command traceert een proces vanaf het opstarten. Gebruik strace -p PID. Voor alles wat multithreaded is of forkt, voeg -f om child-processen te volgen, anders mis je het grootste deel van de activiteit.

Uitvoerregels eindigen met een retourwaarde. -1 ENOENT betekent dat het bestand waar het proces om vroeg, er niet is. -1 EACCES betekent dat er rechten zijn. Die twee fouten zijn op zichzelf al verantwoordelijk voor een verrassend groot deel van de productiebugs.

De handigste vlag is -e trace=GROUP, die de uitvoer beperkt tot een bepaalde categorie systeemaanroepen en de ruis beheersbaar houdt.

Begin op een drukke server met strace -c -p PID gedurende tien of twintig seconden. De -c vlag geeft een overzicht van het aantal syscalls, de totale tijd en fouten wanneer je de verbinding verbreekt. Zo zie je welke categorie de moeite waard is om nader te bekijken, zonder de terminal te overspoelen. Maak vervolgens opnieuw verbinding met een smal filter.

Andere vlaggen die de moeite waard zijn: -T logt de tijd die aan elke aanroep is besteed, -Z toont alleen mislukte aanroepen, en -o file schrijft naar een logbestand in plaats van naar de terminal, wat veel sneller is bij een luidruchtig proces.

CPU profileren met perf

perf heeft vier commando's die je het vaakst zult gebruiken.

Begin met perf stat -p PID voor een snel overzicht. De cijfers om in de gaten te houden:

• IPC (instructies per cyclus) onder 1,0: de CPU loopt vast, meestal bij geheugentoegang.
• Veel LLC-load-misses: de werkverzameling past niet in de cache, dus de CPU wacht op RAM.
• Hoog aantal contextwisselingen: klassiek voor I/O-gebonden workloads waarbij threads blijven blokkeren op schijf of netwerk.

Als er iets niet klopt, ga dan verder met perf record -F 99 -g -p PID -- sleep 30. De -F 99 samples bij 99 Hz, wat voldoende is om hot functions te vinden en synchronisatie met de kernel-timer bij ronde getallen zoals 100 Hz voorkomt. De -g vlag legt call graphs vast, zodat perf report u kan laten zien welke paden naar een functie verantwoordelijk zijn.

In perf reportDe kolom Overhead is het aandeel van het totale aantal samples. Hoge overhead in _int_malloc of memcpy betekent zware toewijzing. Hoge overhead in een van je eigen functies is de hotspot waarnaar je op zoek was.

Als u hex-adressen ziet in plaats van functienamen, is het binaire bestand gestript of ontbreken er debug-symbolen. Installeer het bijbehorende -dbg pakket, of compileer het binaire bestand opnieuw met -g.

Een praktische workflow op een live server

Bij een echt incident op een drukke server ziet de routine er als volgt uit:

1. Controleer het symptoom eerst met eenvoudige tools: top, vmstat, iostat. Als je op een VM werkt, controleer dan de st (steal)-kolom. Alles boven de 5% betekent dat de hypervisor de bottleneck is, niet je code.
2. Als het CPU-gebruik hoog is, voer dan perf top een paar seconden, en voer vervolgens perf record -F 99 -g -p PID -- sleep 30 voor het betreffende proces. Een opname van 30 seconden bij 99 Hz levert ongeveer 1,7 MB aan gegevens op.
3. Als het proces vastloopt, traag is of fouten retourneert, voer dan strace -c -p PID tien seconden en lees de samenvatting. Als één categorie van syscalls overheerst, beperk dan met strace -e trace=GROUP -T -p PID.
4. Wanneer u de verdachte syscall of functie hebt gevonden, verbreek dan de verbinding. Laat geen van beide tools langer dan nodig op de productieomgeving draaien.

Twee waarschuwingen. strace De uitvoer kan omgevingsvariabelen, bestandspaden en bytes bevatten die uit sockets zijn gelezen, dus zuiver de logbestanden voordat u ze buiten uw team deelt. En als u dit regelmatig gaat doen, kijk dan naar bpftrace en de bredere eBPF-toolkit als volgende stap: hetzelfde soort inzicht, minder dan 1% overhead, vanaf het begin gebouwd voor productieomgevingen.

Als u workloads uitvoert waarbij diepgaande diagnostische toegang van belang is en gedeelde infrastructuur geen optie is, kijk dan eens naar onze dedicated servers.