strace och perf för felsökning i Linux

När en Linux-server är långsam, kraschar eller överbelastar processorn och applikationsloggarna inte förklarar varför, täcker två verktyg det mesta av luckan. strace visar vad en process begär av kärnan. perf visar var CPU:n lägger sin tid. Tillsammans besvarar de frågorna ”varför har den fastnat” och ”vad gör den”, vilket inget annat verktyg klarar lika kostnadseffektivt.

Det här inlägget handlar om när du ska använda respektive verktyg, hur du installerar dem, vilka kommandon du faktiskt ska köra och hur du håller driftskostnaderna hanterbara på en live-server.

När ska man använda strace respektive perf

Skillnaden är enkel. Använd perf när CPU:n är upptagen och du behöver veta vilken funktion som är ansvarig. Använd strace när en process hänger sig, kraschar, returnerar konstiga fel eller beter sig på ett sätt som loggarna inte förklarar.

perf samplar kärnans hårdvaruräknare med en konfigurerbar frekvens, så overheaden är vanligtvis under 1 % och det är säkert att köra i produktion. strace avlyssnar varje systemanrop genom ptrace, vilket kan göra målprocessen 10 till 100 gånger långsammare. Använd det sparsamt på live-system och alltid med filter.

Installera strace och perf

Båda verktygen finns i standardrepositorierna. strace bygger på ptrace syscall, som har varit en del av alla moderna kärnor i flera år. perf använder perf_events gränssnittet och kräver ett paket som passar din aktuella kärna.

På Ubuntu eller Debian:

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

På RHEL, AlmaLinux eller Fedora:

sudo dnf install strace perf

Varje $(uname -r) bit är viktig. En perf-binärfil som är byggd mot en annan kärnversion ger förvirrande utdata och kan tysta bort händelser. Verifiera med perf --version och strace -V efter installationen.

För att perf ska visa funktionsnamn istället för hexadresser behöver du felsökningssymboler. Installera relevant -dbg eller -debuginfo paketet (till exempel libc6-dbg på Debian) och kompilera dina egna binärer med -g i GCC.

Inuti containrar strace behövs --cap-add=SYS_PTRACE och perf behövs --cap-add=SYS_ADMIN vid start med Docker. Utan dessa begränsningar misslyckas verktygen på sätt som ser ut som buggar.

Spåra systemanrop med strace

Att köra strace command spårar en process från start. För att ansluta till en pågående process, använd strace -p PID. För allt som är multitrådat eller som förgrenar sig, lägg till -f för att följa barnprocesser, annars missar du det mesta av aktiviteten.

Utmatningsraderna avslutas med ett returvärde. -1 ENOENT betyder att filen som processen begärde inte finns där. -1 EACCES betyder behörigheter. Dessa två fel står själva för en överraskande stor andel av produktionsbuggarna.

Den mest användbara flaggan är -e trace=GROUP, som begränsar utmatningen till en namngiven kategori av systemanrop och håller bruset hanterbart.

På en upptagen server, börja med strace -c -p PID i tio eller tjugo sekunder. Flaggan -c flaggan skriver ut en sammanfattning av antalet systemanrop, total tid och fel när du kopplar bort. Det visar vilken kategori som är värd en närmare titt utan att översvämma terminalen. Koppla sedan in igen med ett snävt filter.

Andra flaggor som är värda att känna till: -T loggar tiden som spenderas på varje anrop, -Z visar endast misslyckade anrop, och -o file skriver till en logg istället för terminalen, vilket är mycket snabbare vid en process med mycket utdata.

Profilera CPU med perf

perf har fyra kommandon som du kommer att använda oftast.

Börja med perf stat -p PID för en snabb översikt. Siffrorna att hålla koll på:

• IPC (instruktioner per cykel) under 1,0: CPU:n stannar upp, vanligtvis vid minnesåtkomst.
• Högt antal LLC-load-misses: arbetsuppsättningen ryms inte i cachen, så CPU:n väntar på RAM.
• Högt antal kontextbyten: klassiskt för I/O-bundna arbetsbelastningar där trådar hela tiden blockeras på disk eller nätverk.

Om något verkar fel, följ upp med perf record -F 99 -g -p PID -- sleep 30. -F 99 samplar vid 99 Hz, vilket är tillräckligt för att hitta heta funktioner och undviker synkronisering med kärntimern vid jämna tal som 100 Hz. -g flaggan fångar upp anropsgrafer så att perf report kan visa vilka vägar in i en funktion som är ansvariga.

I perf reportkolumnen Overhead anges andelen av det totala antalet samplar. Hög overhead i _int_malloc eller memcpy betyder stor allokering. Hög overhead i en av dina egna funktioner är den hotspot du letade efter.

Om du ser hexadresser istället för funktionsnamn är binärfilen strippad eller så saknas felsökningssymboler. Installera motsvarande -dbg paketet, eller bygg om binärfilen med -g.

Ett praktiskt arbetsflöde på en live-server

Vid en verklig incident på en upptagen box ser rutinen ut så här:

1. Bekräfta först symptomen med enkla verktyg: top, vmstat, iostat. Om du använder en virtuell maskin, kontrollera kolumnen st (stjäl) kolumnen. Allt över 5 % betyder att hypervisorn är flaskhalsen, inte din kod.
2. Om CPU-användningen är hög, kör perf top i några sekunder, och sedan perf record -F 99 -g -p PID -- sleep 30 för den aktuella processen. En 30 sekunders inspelning vid 99 Hz ger cirka 1,7 MB data.
3. Om processen har hängt sig, är långsam eller returnerar fel, kör strace -c -p PID i tio sekunder och läs sammanfattningen. Om en syscall-kategori dominerar, begränsa med strace -e trace=GROUP -T -p PID.
4. När du har hittat det misstänkta systemanropet eller funktionen, koppla bort. Låt inte något av verktygen köras i produktionsmiljön längre än nödvändigt.

Två varningar. strace Utdata kan innehålla miljövariabler, filvägar och byte som lästs från socklar, så rensa loggarna innan du delar dem utanför ditt team. Och om du ska göra detta regelbundet, titta på bpftrace och det bredare eBPF-verktygssetet som nästa steg: samma typ av insyn, mindre än 1 % overhead, byggt för produktion från början.

Om du kör arbetsbelastningar där djup diagnostisk åtkomst är viktig och delad infrastruktur inte är ett alternativ, ta en titt på våra dedikerade servrar.