strace e perf per la risoluzione dei problemi su Linux

Quando un server Linux è lento, va in crash o consuma troppa CPU e i log dell'applicazione non spiegano il motivo, due strumenti colmano gran parte del divario. strace strace indica cosa sta richiedendo un processo al kernel. perf ti dice dove la CPU sta impiegando il suo tempo. Insieme rispondono alle domande "perché è bloccato" e "cosa sta facendo" che nessun altro strumento gestisce in modo così economico.

Questo post spiega quando ricorrere a ciascuno strumento, come installarli, i comandi da eseguire effettivamente e come mantenere gestibile il sovraccarico su un server in produzione.

Quando utilizzare strace rispetto a perf

La distinzione è semplice. Usa perf quando la CPU è occupata e devi sapere quale funzione ne è responsabile. Usa strace quando un processo si blocca, va in crash, restituisce errori strani o si comporta in un modo che i log non spiegano.

perf campiona i contatori hardware del kernel a una frequenza configurabile, quindi l'overhead è solitamente inferiore all'1% ed è sicuro da eseguire in produzione. strace intercetta ogni chiamata di sistema tramite ptrace, il che può rallentare il processo di destinazione da 10 a 100 volte. Usalo con parsimonia sui sistemi live e sempre con dei filtri.

Installazione di strace e perf

Entrambi gli strumenti si trovano nei repository standard. strace si basa sul ptrace syscall, che da anni fa parte di ogni kernel moderno. perf utilizza l' perf_events e necessita di un pacchetto compatibile con il kernel in uso.

Su Ubuntu o Debian:

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

Su RHEL, AlmaLinux o Fedora:

sudo dnf install strace perf

Il $(uname -r) bit è importante. Un binario perf compilato per una versione diversa del kernel produce un output confuso e potrebbe ignorare silenziosamente alcuni eventi. Verificare con perf --version e strace -V dopo l'installazione.

Affinché perf mostri i nomi delle funzioni invece degli indirizzi esadecimali, sono necessari i simboli di debug. Installare il file -dbg o -debuginfo (ad esempio, libc6-dbg su Debian), e compilare i propri binari con -g in GCC.

All'interno dei container, strace è necessario --cap-add=SYS_PTRACE e perf è necessario --cap-add=SYS_ADMIN durante l'avvio con Docker. Senza questi limiti, gli strumenti falliscono in modi che sembrano bug.

Tracciamento delle chiamate di sistema con strace

L'esecuzione di strace command traccia un processo dal momento del suo avvio. Per collegarsi a un processo in esecuzione, utilizzare strace -p PID. Per qualsiasi processo multithread o che esegue il fork, aggiungere -f per seguire i processi figli, altrimenti si perderà la maggior parte dell'attività.

Le righe di output terminano con un valore di ritorno. -1 ENOENT significa che il file richiesto dal processo non è presente. -1 EACCES indica i permessi. Questi due errori da soli rappresentano una percentuale sorprendente dei bug in produzione.

Il flag più utile è -e trace=GROUP, che limita l'output a una categoria di chiamate di sistema specificata e mantiene il rumore gestibile.

Su un server molto trafficato, inizia con strace -c -p PID per dieci o venti secondi. Il -c flag stampa un riepilogo del conteggio delle chiamate di sistema, del tempo totale e degli errori quando ci si stacca. Questo ti dice quale categoria merita un'occhiata più da vicino senza intasare il terminale. Quindi ricollegati con un filtro ristretto.

Altri flag che vale la pena conoscere: -T registra il tempo impiegato in ogni chiamata, -Z mostra solo le chiamate fallite e -o file scrive su un log invece che sul terminale, il che è molto più veloce in un processo rumoroso.

Profilazione della CPU con perf

perf dispone di quattro comandi che userete la maggior parte delle volte.

Inizia con perf stat -p PID per una rapida panoramica. I numeri da tenere d'occhio:

• IPC (istruzioni per ciclo) inferiore a 1,0: la CPU è in stallo, solitamente durante l'accesso alla memoria.
• Elevato numero di LLC-load-miss: il working set non entra nella cache, quindi la CPU è in attesa della RAM.
• Elevato numero di cambi di contesto: tipico dei carichi di lavoro legati all'I/O in cui i thread continuano a bloccarsi sul disco o sulla rete.

Se qualcosa sembra strano, approfondisci con perf record -F 99 -g -p PID -- sleep 30. I -F 99 campiona a 99 Hz, il che è sufficiente per individuare le funzioni più attive ed evita la sincronizzazione con il timer del kernel a valori tondi come 100 Hz. Il -g flag acquisisce i grafici delle chiamate, quindi perf report possa mostrarti quali percorsi all'interno di una funzione sono responsabili.

Nella perf report, la colonna Overhead rappresenta la percentuale sul totale dei campioni. Un overhead elevato in _int_malloc o memcpy indica un'allocazione pesante. Un overhead elevato in una delle tue funzioni è l'hotspot che stavi cercando.

Se vedete indirizzi esadecimali invece dei nomi delle funzioni, il binario è stato sottoposto a stripping oppure mancano i simboli di debug. Installate il -dbg , oppure ricompila il binario con -g.

Un flusso di lavoro pratico su un server attivo

Per un incidente reale su un dispositivo molto trafficato, la procedura è la seguente:

1. Verifica prima il sintomo con strumenti semplici: top, vmstat, iostat. Se si utilizza una macchina virtuale, controllare la st colonna (steal). Qualsiasi valore superiore al 5% significa che l’hypervisor è il collo di bottiglia, non il tuo codice.
2. Se l'utilizzo della CPU è elevato, esegui perf top per alcuni secondi, quindi perf record -F 99 -g -p PID -- sleep 30 per il processo incriminato. Una cattura di 30 secondi a 99 Hz produce circa 1,7 MB di dati.
3. Se il processo è bloccato, lento o restituisce errori, esegui strace -c -p PID per dieci secondi e leggi il riepilogo. Se una categoria di chiamate di sistema è predominante, restringi il campo con strace -e trace=GROUP -T -p PID.
4. Una volta individuata la chiamata di sistema o la funzione sospetta, stacca il processo. Non lasciare nessuno dei due strumenti in esecuzione sull'ambiente di produzione più a lungo del necessario.

Due avvertenze. strace L'output può includere variabili d'ambiente, percorsi di file e byte letti dai socket, quindi ripulite i log prima di condividerli al di fuori del vostro team. E se avete intenzione di farlo regolarmente, date un'occhiata a bpftrace e al più ampio toolkit eBPF come passo successivo: lo stesso tipo di visibilità, un overhead inferiore all’1%, progettato per la produzione fin dall’inizio.

Se esegui carichi di lavoro in cui è importante un accesso diagnostico approfondito e l'infrastruttura condivisa non è un'opzione, dai un'occhiata ai nostri server dedicati.