PIDSTAT Linux: analizzare l'utilizzo della CPU e della memoria dei singoli processi

Con pidstat Su Linux misuro l'attività della CPU, della memoria, dell'I/O e dei thread per ogni processo a intervalli fissi, riuscendo così a individuare le tendenze anziché limitarmi a istantanee. In questo modo riesco a Colli di bottiglia affidabile: assegnalo a un PID o a un comando e stabilisci se la causa è da ricercarsi nella CPU, nella RAM, nell'I/O o in un cambio di contesto.

Punti centrali

• Misurazione a intervalli: serie temporali per ogni processo anziché semplici istantanee.
• Ampia copertura: CPU, memoria, I/O, thread e cambio di contesto.
• Filtraggio mirato: Osservare con messa a fuoco tramite PID o comando.
• Facile da usare: installare sysstat, avviarlo immediatamente.
• Vantaggi pratici: Individuare rapidamente i picchi di carico, le perdite e i colli di bottiglia I/O.

Che cos’è pidstat? Una breve spiegazione

Uso pidstat, per rendere visibile l'utilizzo delle risorse da parte dei singoli processi nel tempo. Lo strumento fa parte del pacchetto sysstat e fornisce, per ogni processo, dati relativi a CPU, memoria, I/O, thread e cambi di contesto. A differenza di top, non ottengo una visione fugace, ma punti di misurazione continui a intervalli regolari. In questo modo riesco a individuare modelli quali picchi periodici, carico costante o crescita graduale. Queste informazioni temporali mi aiutano ad attribuire chiaramente le cause a un processo specifico, senza perdermi nel rumore di un’istantanea.

Installazione e messa in funzione rapida

Installo sysstat con il gestore di pacchetti della mia distribuzione e avvio subito pidstat senza alcuna configurazione aggiuntiva. La sintassi di base rimane semplice: pidstat [opzioni] [intervallo] [numero]. Senza opzioni, lo strumento mostra CPU- Valori per ogni processo; le misurazioni vengono ripetute continuamente a intervalli regolari. Esempio: pidstat 2 10 Raccoglie dieci rilevamenti ogni due secondi. In questo modo riesco a creare rapidamente una cronologia affidabile per l'ulteriore analisi.

Analisi della CPU: visualizzare il carico per processo

Per le domande sulla CPU, inizio pidstat con -u, ad esempio pidstat -u 1 per ogni secondo. Le colonne %usr, %system e %CPU mi indicano quanto tempo utente e tempo kernel occupa un processo. Se ho bisogno di concentrarmi su un’applicazione, utilizzo -p oppure -C per i filtri basati sul nome. Se %system aumenta notevolmente, verifico le chiamate di sistema o gli effetti dell’I/O; se prevale %usr, il lavoro si svolge nello spazio utente. Per un’analisi più approfondita per singolo processo, rimando, se necessario, anche a Contabilità di processo, al fine di analizzare in modo strutturato i dati di utilizzo.

Verificare in modo mirato l'utilizzo della memoria

Per quanto riguarda gli argomenti relativi alla RAM, offre -r preziose informazioni, ad esempio con pidstat -r -p 1234 1. Osservo l'andamento della memoria occupata virtualmente e di quella residente nel corso dei minuti e verifico se i page fault aumentano. Se il consumo aumenta costantemente a piccoli passi, riesco a individuare tempestivamente eventuali perdite di memoria. Se il fabbisogno rimane costante e aumenta solo in brevi fasi, ciò indica un utilizzo legittimo Caching . Grazie alla misurazione a intervalli, riesco a distinguere chiaramente i valori anomali dalle tendenze reali.

Comprendere l'I/O e il cambio di contesto

Con -d mostro l'attività di lettura e scrittura per ogni processo e individuo così le cause dei tempi di attesa elevati sul supporto dati. Velocità di trasferimento elevate, unite a latenze crescenti, fanno supporre la presenza di colli di bottiglia nello storage. Inoltre, verifico con -w i cambi di contesto al secondo, poiché cambi eccessivi possono generare un sovraccarico inutile. Un numero elevato di cambi volontari (vswch/s) indica una sincronizzazione; un numero elevato di cambi forzati (cswch/s) indica una forte competizione per il tempo di CPU. In questo modo individuo i carichi di lavoro inefficienti, che poi risolvo in modo mirato.

Monitorare i thread e individuare i punti critici

Utilizzo -t, pidstat fornisce anche i valori relativi ai thread per ogni processo. In questo modo posso verificare se singoli worker di un’applicazione presentano valori anomali. Nel caso di Java, PHP-FPM, database o worker di coda, riesco così a individuare i thread che occupano eccessivamente la CPU o causano un aumento della memoria. Se rilevo squilibri, regolo i pool di thread, le affinità o Limiti . Questa prospettiva mi aiuta a ottimizzare non solo i processi, ma anche il loro parallelismo interno.

Panoramica delle opzioni principali

Utilizzo gli interruttori principali in modo mirato per Analisi per lavorare in modo mirato e mantenere le uscite leggibili. La tabella seguente riassume in modo sintetico le opzioni principali e gli impieghi tipici. In questo modo posso selezionare rapidamente l’interruttore adatto per CPU, memoria, I/O, thread o filtri. Gli esempi mi aiutano a iniziare senza perdite di tempo. Ogni riga mi fornisce una chiara Suggerimento in base alla destinazione d'uso.

Opzione	Funzione	Esempio
-u	Visualizza l'utilizzo della CPU per ogni processo	pidstat -u 1
-r	Valori relativi alla memoria e agli errori di pagina	pidstat -r -p 1234 2
-d	Attività I/O di lettura/scrittura	pidstat -d 1
-w	Cambiamento di contesto per ciascun processo	pidstat -w -p 1234 1
-t	Mostra le statistiche del thread	pidstat -t -p 1234 1
-p	Limitare a ID di processo specifici	pidstat -u -p 1234 1
-C	Filtrare i processi tramite comando	pidstat -C php-fpm 2

Filtri, intervalli e monitoraggio mirato

Sto programmando delle misurazioni con Intervalli, che si adattano alla domanda: secondi per gli atleti di discipline di velocità, minuti per gli sciatori di fondo. Su -p e -C In questo modo limito l'output ai processi rilevanti e mantengo la console ben organizzata. pidstat 2 10 È ideale per prove brevi; senza specificare un numero, continuo a misurare finché non interrompo il processo. Per i controlli ricorrenti, inserisco i comandi negli script e documento i Linea di base di un sistema. Questa procedura consente di risparmiare tempo qualora si presentassero nuovamente problemi di carico.

Confronto con top, ps e simili.

Per una rapida panoramica utilizzo top oppure ps, ma per l'andamento e il livello di dettaglio ricorro a pidstat. I valori intervallati mi consentono di individuare le cause nel tempo, anziché limitarmi a osservare i sintomi. Se ho bisogno di una visione più approfondita dei colli di bottiglia della CPU, integro l'analisi con Linux perf per campioni degli stack di chiamata. In questo modo combino le statistiche di processo con il profiling, quando i soli valori di carico non sono sufficienti. Questa combinazione mi fornisce indicazioni rapide e una solida Diagnosi.

Consigli pratici per la vita di tutti i giorni

Tengo a portata di mano una serie di comandi collaudati e li adatto alla situazione per Sistemi di produzione. Carico della CPU in tempo reale: pidstat -u 1. Memoria con messa a fuoco: pidstat -r -p 2. Verificare la presenza di un collo di bottiglia nell'I/O: pidstat -d 1. I thread in primo piano: pidstat -t -p 1. Per una strumentazione di sistema più approfondita, ricorro inoltre a Suggerimenti su bpftrace quando gli eventi del kernel richiedono Spotlight.

Leggere correttamente l'output: linee temporali e sistemi multicore

Presto attenzione al modo in cui pidstat imposta i riferimenti temporali: Il primo blocco di misurazione Per impostazione predefinita, mostra i valori medi dall'avvio del processo (o dall'avvio del sistema); tutti i blocchi successivi si riferiscono all'opzione selezionata Intervallo. Per analisi approfondite, spesso ignoro il primo blocco e prendo in considerazione solo i valori degli intervalli comparabili nel tempo.

All'indirizzo Sistemi multicore Interpreto sempre il valore %CPU nel contesto dei core disponibili. Un singolo processo su un host a 8 core può teoricamente raggiungere fino a 800% se scala su più thread. Valori elevati di %system mi fanno pensare a chiamate di sistema, contesa sui lock o code di attesa I/O; valori elevati di %usr indicano routine ad alta intensità di calcolo nello spazio utente. Il timestamp che precede ogni riga rende chiaramente riconoscibili i valori anomali nell’andamento e facilita la correlazione con i log o le metriche provenienti da altre fonti.

Metodologia: formulare ipotesi, scegliere gli intervalli di misurazione

Non mi lancio mai alla cieca, ma formulo una Ipotesi Per quanto riguarda la causa: „CPU-bound nello spazio utente“, „code I/O intasate“, „la memoria cresce costantemente“. Da qui deduco la finestra di misurazione: in caso di picchi brevi utilizzo intervalli di 1–2 secondi, in caso di Sciatori di fondo piuttosto 10–60 secondi. È importante regolare la finestra in base alla Dinamica del sistema, in modo da non perdere alcun dettaglio né raccogliere una quantità eccessiva di rumore.

Inoltre, effettuo misurazioni prima e dopo Cambiamenti (ad es. rilascio, ottimizzazione della configurazione) per rendere visibili gli effetti nelle metriche. Una chiara Linea di base per ogni ambiente (DEV, STAGE, PROD) mi aiuta a distinguere le vere anomalie dai modelli normali.

Registrazione permanente e follow-up

Quando mi trovo di fronte a problemi difficili da cogliere, prendo appunti per un periodo di tempo definito e poi li analizzo. Esempio: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log raccoglie per 30 minuti i dati relativi a CPU, I/O, cambi di contesto e thread con intervalli di 2 secondi. Posso utilizzare l'output testuale strutturato con grep, awk o un breve script post-elaborazione, evidenziare i picchi ed estrarre i PID più evidenti. Per le osservazioni ricorrenti ho in programma di Schema di rotazione e seleziona solo le fasce orarie rilevanti, per risparmiare spazio.

Quando ho bisogno di più punti di vista, combino i comandi in un’unica sequenza, invece di avviare più strumenti in parallelo. Questo garantisce che i risultati delle misurazioni sincrono e semplifica l'analisi.

Container, spazi dei nomi e PID

Negli ambienti container si applica quanto segue: I PID sono associati a uno spazio dei nomi. Se effettuo la misurazione sull’host, vedo i PID dell’host; se la effettuo nel container, vedo i PID del container. Per un’assegnazione univoca, preferisco quindi filtrare in base al nome del comando con -C piuttosto che con un singolo PID, che cambia dopo un riavvio. Se lavoro sul lato host, integro il contesto del processo (ad esempio tramite il nome del servizio o del pod nei log), in modo da poter associare in seguito i valori misurati in modo chiaro a un Carico di lavoro da assegnare. Per le registrazioni di lunga durata evito la trappola del PID (Riutilizzo del PID) anche tramite filtri basati sui nomi o tramite log di accompagnamento che documentano la durata del PID.

Misurazioni affidabili in produzione: costi generali, diritti, protezione dei dati

Spese generali: pidstat legge principalmente da /proc e richiede solo un minimo sforzo di monitoraggio. In caso di intervalli molto brevi su host sottoposti a carico elevato, aumento leggermente l'intervallo (ad esempio da 1 a 2 secondi) per ridurre ulteriormente l'impatto sulla CPU. Effettuo misurazioni mirate (filtri!) anziché „tutto e ovunque“.

Diritti e sicurezza: A seconda della configurazione del sistema (hidepid all'indirizzo /proc) i dettagli non sono visibili a tutti gli utenti. Nell'ambiente di produzione, se necessario, lavoro con privilegi più elevati, riduco al minimo la durata della misurazione e verifico se la visualizzazione completa Riga di comando potrebbe rivelare parametri sensibili. I log contenenti dati diagnostici devono essere conservati solo in luoghi in cui possano essere archiviati e cancellati in modo sicuro.

Riconoscere rapidamente gli schemi tipici

• Elevato sistema 1TP1 con moderata %usr: Indicazione di punti critici legati al kernel (uso intensivo delle chiamate di sistema, contesa sui lock, percorsi dei driver di rete/storage). Metto in correlazione questi dati con i valori di I/O e i cambi di contesto.
• Numerosi cambi di contesto forzati (cswch/s): Forte competizione per il tempo di CPU, spesso causata da risorse della CPU insufficienti o da un numero eccessivo di thread attivi. Limitare l'utilizzo, regolare le dimensioni dei pool oppure Affinità controllo.
• Molti cambi di contesto volontari (vswch/s): Sincronizzazione marcata oppure resacode di attesa basate su -. Analizzo i lock, le strategie di backoff e il comportamento del thread pool.
• Spazio di archiviazione in costante aumento: Sospetta fuga di informazioni. Sto verificando se Errori della pagina (in particolare majflt) aumenti e se il processo liberi nuovamente memoria dopo i picchi di carico. Se non lo fa, lo dimostro con una misurazione a intervalli più lunghi.
• Elevate velocità di trasferimento I/O con una bassa produttività del sistema: Se considerati insieme ai tempi di attesa, i valori di I/O dei processi indicano la presenza di colli di bottiglia nello stack di storage sottostante. Do priorità alle misure di ottimizzazione dell'I/O (batching, caching, I/O asincrono).
• Alcuni thread spiccano tra gli altriCon -t Individuo l„“Hot Thread” e regolo il thread pool oppure analizzo in modo mirato il suo percorso di esecuzione.

Flussi di lavoro tratti dalla pratica

Identificare i punti limitanti a livello di CPU: Innanzitutto pidstat -u 1 a livello globale, poi in modo mirato con -p oppure -C. Se il valore sale di %usr, cerco l'Hot Thread con -t e, se necessario, analizzo i dati tramite il profiler di campionamento. Se predominano i sistemi 1TP1, do un’occhiata anche all’I/O e ai cambi di contesto.

Confermare la presenza di una perdita di memoria: Per diversi minuti con pidstat -r -p 5 osservare. Sto documentando un aumento costante senza cali dopo le fasi di carico. Parallelmente, sto verificando se i tassi di page fault o i modelli di I/O possano spiegare tale comportamento. Se la tendenza persiste senza una giustificazione valida, si tratta di un chiaro Indicatore di perdite.

Individuare i colli di bottiglia I/OCon pidstat -d 1 Individuo i punti critici di lettura/scrittura. Se rilevo un carico di scrittura significativo causato da pochi processi, mi concentro sui loro percorsi di flush/sincronizzazione e sulle dimensioni dei batch. La correlazione con i cambi di contesto mi aiuta a capire se, contemporaneamente, la CPU viene sottoposta a pressione.

Risolvere il problema dello squilibrio del filo: pidstat -t -p 1 mi mostra il carico e i cambi di contesto per ogni thread. Se un worker si surriscalda notevolmente rispetto agli altri, adeguo le dimensioni del pool, la distribuzione dei compiti o Affinità e verifica se la distribuzione si normalizza negli intervalli successivi.

Limiti di pidstat e integrazioni utili

pidstat mostra cosa consumato risorse e quando succede – ma questo non spiega automaticamente il perché nel percorso del codice. Per capire il „perché“, utilizzo in aggiunta il profiler di campionamento o i punti di tracciamento del kernel. Per quanto riguarda le questioni relative alla memoria, pidstat mette in luce le tendenze, ma non i cicli di vita degli oggetti. Considero quindi pidstat come Primo soccorso, che mi permette di individuare le aree problematiche con il minimo sforzo. Laddove i semplici valori di carico non sono più sufficienti, approfondisco l’analisi in modo mirato utilizzando gli strumenti già citati.

Lista di controllo per l'avvio rapido

• Affinare la domanda: CPU, RAM, I/O, thread o cambio di contesto?
• Selezionare l'intervallo: Secondi per i picchi, minuti per le tendenze.
• Imposta filtro: -p oppure -C utilizzare per mantenere la resa snella.
• Prima una panoramica, poi un approfondimento: Avviare a livello globale, individuare i processi che destano sospetti.
• Inserire il primo blocco: La prima riga è stata calcolata come media dall'inizio; successivamente si confrontano i valori degli intervalli.
• Limitare la durata della misurazione: Raccogliere dati sufficienti per individuare le tendenze, ma senza perdere il controllo dei log.
• Documentare: Registrare la linea di base, l’ipotesi, i parametri di misurazione e le osservazioni: è questo che rende le analisi riproducibili.

Riassumendo brevemente

Con pidstat Ricevo dati di processo basati sul tempo relativi a CPU, RAM, I/O, thread e cambi di contesto, e in questo modo individuo le vere cause dei modelli di carico. La combinazione di filtri, intervalli e indicatori chiari rende le analisi mirate e riproducibili. Riesco a individuare le tendenze, invece di farmi ingannare da istantanee, e ad adottare le contromisure adeguate. Comandi come pidstat -u 1, -r, -d e -w coprono i casi più comuni. In questo modo garantisco che i sistemi siano trasparenti, le decisioni rapide e le diagnosi comprensibile.