8 comandi essenziali per monitorare l'uso CPU su Linux

Quando la CPU sale, la domanda giusta non è “quanta percentuale vedo?”, ma “chi sta consumando, su quale core, con quale tipo di attesa e con quale effetto sul servizio”. Su Linux la risposta arriva solo se incroci almeno tre livelli: vista globale del sistema, lista dei processi, e osservazione del comportamento nel tempo. I comandi sotto coprono quel percorso senza trasformare il debug in un giro di schermate inutili.

Il punto pratico è questo: una CPU al 90% non è sempre un problema, mentre un server apparentemente al 30% può essere già in saturazione se la latenza cresce, i run queue si allungano o il tempo passa in iowait. Per questo i comandi qui sotto non sono messi in ordine “da manuale”, ma secondo la sequenza con cui li userei su una macchina in produzione.

1. top: il primo colpo d’occhio sul sistema

top resta il comando più veloce per capire se il problema è globale o concentrato su pochi processi. Lo apri e guardi subito %us, %sy, %id, %wa e il numero di task attivi. Se %wa è alto, il collo di bottiglia non è la CPU in senso stretto: stai aspettando storage o rete.

Avvio utile:

top

Se vuoi una lettura più pulita, ordina per CPU con P. In ambienti con molti thread, il valore importante non è solo la riga del processo, ma anche la colonna nTH e la distribuzione sui core. Un processo che sembra “moderato” può in realtà avere decine di thread che si contendono la CPU e peggiorano la latenza.

Indicatore operativo: se il load average cresce ma %id è ancora alto, non stai per forza saturando la CPU. Potresti avere processi bloccati in I/O o una coda di run queue che si accumula per lock interni. top è il filtro iniziale, non la diagnosi finale.

2. htop: leggere meglio i core e i thread

htop aggiunge due cose che in troubleshooting contano molto: visualizzazione più chiara dei core e navigazione rapida tra i processi. Se installato, è spesso più utile di top quando devi individuare un thread specifico o distinguere un carico distribuito da uno concentrato. Sul campo, la differenza vera è che vedi subito se un singolo core è inchiodato mentre gli altri sono quasi fermi.

Avvio:

htop

Con F6 puoi cambiare ordinamento, con F5 puoi espandere l’albero dei processi, e con F2 puoi mostrare colonne aggiuntive come Processor, NLWP o IO_RATE se la build le supporta. Se stai cercando un picco intermittente, lascia il pannello aperto e osserva il processo per qualche minuto: il comportamento temporale conta più del valore istantaneo.

Osservazione utile: in container o ambienti con cgroup, htop può mostrare il carico del namespace ma non sempre il limite effettivo applicato dal runtime. Se il pod o il servizio è limitato a un core e mezzo, il 100% visualizzato può essere già il tetto reale, non un problema del kernel.

3. mpstat: capire se il problema è su tutti i core o solo su uno

mpstat viene spesso sottovalutato, ma è uno dei comandi più puliti per leggere la distribuzione della CPU per core e per intervallo. È il modo migliore per capire se hai un core saturato, un bilanciamento scarso o un carico davvero uniforme. Su sistemi multi-core è più informativo di una singola riga di sintesi.

Comando tipico:

mpstat -P ALL 1

Con questo vedi ogni secondo il dettaglio per tutti i core. Se un solo core resta alto mentre gli altri dormono, il sospetto va su un processo single-thread, su IRQ sbilanciate o su un lock molto conteso. Se invece tutti i core sono alti e il valore di %steal cresce in VM, il problema può stare nell’host hypervisor.

Per una prima lettura, controlla tre colonne: %usr, %sys e %steal. In virtualizzazione, %steal è spesso la riga che smonta ipotesi sbagliate: la macchina sembra lenta, ma in realtà la CPU le viene sottratta dall’hypervisor.

4. pidstat: trovare il processo colpevole senza affidarti al caso

pidstat è il comando da usare quando vuoi passare dalla vista di sistema alla vista per processo senza perdere il contesto temporale. A differenza di ps, ti dice come si muove il consumo nel tempo. A differenza di top, puoi filtrare e raccogliere dati in modo ripetibile.

Per vedere i processi più attivi:

pidstat -u 1

Se vuoi includere anche i thread:

pidstat -u -t 1

Qui la lettura corretta è cercare due cose: un PID che cresce in modo coerente, oppure tanti thread con consumo moderato ma persistente. Il secondo caso è tipico di applicazioni Java, runtime web con pool di worker, motori di ricerca interni e servizi che fanno parallelismo aggressivo.

Se hai bisogno di un filtro mirato, puoi limitarti a un PID preciso:

pidstat -u -p 1234 1

Questo è il passaggio che evita il classico errore da troubleshooting: inseguire il processo sbagliato perché il picco è già passato. Con la raccolta a intervallo, il colpevole emerge anche se il carico è breve ma ricorrente.

5. ps: classificare rapidamente i processi più pesanti

ps non è interattivo, ma resta fondamentale per una fotografia rapida e automatizzabile. Il suo pregio è che puoi usarlo in pipeline, salvare l’output e confrontarlo in seguito. Quando la macchina è sotto stress, avere una riga testuale è spesso meglio di un tool grafico o interattivo.

Per ordinare i processi per uso CPU:

ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu | head -20

Se vuoi includere l’utente e il comando completo:

ps -eo user,pid,ppid,stat,comm,args,%cpu --sort=-%cpu | head -20

Questo comando è utile quando devi capire se il consumo arriva da un demone di sistema, da un job schedulato o da un processo lanciato manualmente. La colonna STAT aiuta anche a distinguere un processo realmente attivo da uno in stato dormiente ma ancora presente nella classifica per effetto della media calcolata dal kernel.

Se stai facendo un’analisi ripetibile, salva l’output e confrontalo con un secondo campione dopo 30 o 60 secondi. La stabilità del sospetto conta più del valore assoluto in un singolo istante.

6. vmstat: leggere run queue, swap e iowait insieme

vmstat è uno di quei comandi che sembrano vecchi finché non ti serve capire se la CPU è davvero il problema o se è solo il sintomo. Ti mostra insieme processi, memoria, swap, I/O e CPU. Il vantaggio è che puoi correlare la coda di esecuzione con il comportamento del sistema in un solo colpo.

Avvio tipico:

vmstat 1

Le colonne da guardare sono r, us, sy, id, wa e, se presenti, si/so. Se r è più alto del numero di core per un tempo significativo, hai una run queue in crescita: il sistema non sta riuscendo a schedulare tutto subito. Se wa è alto, la CPU aspetta dati da storage o da un backend lento.

Un caso classico: CPU apparentemente libera, ma r cresce e la latenza applicativa peggiora. Qui il problema può essere un lock interno, non il consumo raw di CPU. Per questo vmstat serve a non fare diagnosi superficiali.

7. sar: storico leggero per capire se il picco è un evento o una tendenza

sar è il comando giusto quando il problema non è presente mentre guardi. Se hai abilitato sysstat, puoi recuperare dati storici sulla CPU e capire se il picco è iniziato dopo un deploy, un backup, una finestra batch o un cambio di traffico. In produzione questo vale più di cento screenshot presi troppo tardi.

Esempio di lettura storica:

sar -u -f /var/log/sysstat/sa$(date +%d)

Il path può cambiare a seconda della distribuzione e della configurazione di sysstat, ma il concetto è lo stesso: consultare il file raccolto dall’agent di sistema. Se vedi un aumento stabile di %usr o %sys in una fascia oraria precisa, hai già un indizio forte sulla causa esterna.

Se il tuo obiettivo è confrontare una finestra specifica, usa l’intervallo con attenzione e incrocia il dato con i log applicativi. Il valore di sar sta nel tempo, non nella foto istantanea.

8. perf top: quando serve capire dove finisce davvero il tempo CPU

Se i comandi precedenti ti dicono quale processo consuma CPU ma non perché, perf top è il passo successivo. Ti mostra le funzioni più costose nel profilo live, quindi è utile per distinguere calcolo puro, syscall ripetute, lock contention e overhead del kernel. È il comando da usare quando il processo è noto ma il motivo del consumo non lo è.

Avvio base:

sudo perf top

La lettura è semplice: osservi le funzioni in cima alla lista e cerchi pattern anomali. Se il tempo è tutto in una funzione della tua applicazione, la strada è nel codice o nella configurazione. Se invece domina una syscall o una funzione kernel, il problema può essere I/O, rete o scheduling. In ambienti web, questo è spesso il punto in cui si scopre che il “problema CPU” è in realtà un effetto collaterale di una dipendenza lenta.

Se vuoi un’analisi più mirata, puoi combinare perf top con un PID specifico, ma qui conviene muoversi con cautela: stai già entrando in diagnostica avanzata e serve sapere cosa stai misurando, non solo guardare numeri che si muovono.

Sequenza pratica da usare in produzione

Se il server è lento e vuoi evitare giri a vuoto, usa questa sequenza:

1. top o htop per capire se il problema è globale o concentrato.

2. mpstat -P ALL 1 per vedere se la pressione è su un solo core o su tutti.

3. pidstat -u -t 1 per trovare il processo o il thread responsabile.

4. ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu | head per una fotografia rapida e salvabile.

5. vmstat 1 per distinguere CPU vera da attesa I/O o run queue.

6. sar -u se il picco non è più presente e devi tornare indietro nel tempo.

7. perf top se il processo è noto ma la causa interna no.

Questa sequenza riduce il numero di ipotesi sbagliate. Per esempio, se mpstat mostra un solo core al limite e pidstat identifica un processo single-thread, non serve inseguire il database o il kernel. Se invece vmstat mostra wa alto, la CPU potrebbe essere solo il sintomo di uno storage lento o di una dipendenza esterna.

Errori comuni quando si monitora la CPU

Il primo errore è leggere solo la percentuale totale e fermarsi lì. Su un sistema moderno la distribuzione conta più del totale, soprattutto con servizi multi-thread e VM. Il secondo errore è confondere %usr con “problema applicativo” e %sys con “problema kernel”: spesso il confine è meno netto, perché un’applicazione può forzare syscall, lock o I/O che spostano il costo nel kernel.

Il terzo errore è ignorare la memoria e lo storage. Una CPU alta può essere causata da compressione, garbage collection, spinlock o retry aggressivi. Viceversa, una CPU bassa con latenza alta può dipendere da iowait o da throttling dell’ambiente virtualizzato. Se guardi un solo numero, rischi di curare il sintomo sbagliato.

Che cosa osservare prima e dopo una correzione

Se applichi una modifica, misura almeno tre cose: uso CPU, latenza del servizio e numero di processi o thread attivi. In pratica: prima e dopo il change confronta il valore di %usr o %sys, il p95 della risposta applicativa e la run queue. Senza questo confronto, non sai se hai migliorato il sistema o solo spostato il carico altrove.

Quando il problema è intermittente, salva un campione con timestamp. Anche un semplice output di pidstat o sar archiviato in /var/tmp può fare la differenza tra una diagnosi veloce e una caccia al fantasma. La CPU non va letta come fotografia isolata: va letta come sequenza di eventi.

Conclusione operativa

I comandi davvero utili per monitorare l’uso CPU su Linux non sono quelli che “mostrano la percentuale”, ma quelli che ti dicono dove si concentra la pressione, se è persistente e quale componente la sta generando. top e htop servono per l’impatto immediato, mpstat e vmstat per capire la natura del carico, pidstat e ps per isolare il colpevole, sar per lo storico e perf top per entrare nel dettaglio quando il processo è già noto.

Se li usi nell’ordine giusto, smetti di “guardare la CPU” e inizi a leggere un sistema. Ed è lì che il troubleshooting smette di essere intuitivo e diventa affidabile.