Linux: trovare il processo che satura CPU, RAM e I/O

Introduzione

Quando un server Linux rallenta, la tentazione è intervenire subito su Apache, PHP, MySQL o sul pannello di controllo. In realtà, quasi sempre il problema vero è più semplice da identificare: un processo che consuma troppa CPU, una memoria esaurita, un disco lento o una coda I/O bloccata.

La strada più efficace non è “toccare tutto”, ma seguire una sequenza stabile: osservare i sintomi, misurare le risorse, capire quale processo sta esagerando e solo dopo applicare la correzione minima. Questo approccio evita fix casuali, riduce il rischio di peggiorare la situazione e aiuta a distinguere un problema temporaneo da un guasto strutturale.

Questa guida è pensata per Ubuntu, Debian, AlmaLinux, Rocky Linux e CentOS. I comandi sono volutamente semplici e verificabili, così puoi usarli sia su VPS piccoli sia su server dedicati.

1. Prima di cambiare qualcosa: stabilisci il sintomo

Prima domanda: il server è lento, il sito va in timeout, il backend non risponde o una singola applicazione è bloccata? La risposta cambia il tipo di controllo da fare. Se il problema è generale, devi guardare CPU, RAM e disco. Se è un solo sito o un solo servizio, devi anche controllare il processo padre: PHP-FPM, MariaDB, nginx, Apache, Redis o il pannello hosting.

Se hai accesso SSH, la prima fotografia utile è questa:

uptime

Il valore di load average non dice tutto, ma è un indicatore rapido: se è molto alto rispetto al numero di core e il server risponde male, c’è probabilmente saturazione. Su un server a 2 core, valori costantemente sopra 2-3 meritano attenzione; su macchine più grandi va interpretato con più contesto.

Per capire se il problema è recente o persistente, controlla anche quanto tempo il server è sotto carico e se ci sono stati riavvii o crash recenti.

who -b

Esito atteso: visualizzare l’ultimo boot. Se il sistema si è appena riavviato, il problema potrebbe essere un processo che entra in crisi dopo l’avvio o un picco di traffico improvviso.

2. Verifica CPU, RAM e swap in pochi secondi

Il comando più utile per una prima lettura è top o, se disponibile, htop. Il primo è quasi sempre presente, il secondo è più leggibile. Cerca queste condizioni:

• CPU vicina al 100% su uno o più core.
• RAM quasi esaurita.
• Swap in uso crescente.
• Uno o pochi processi in cima alla lista consumano molto più degli altri.

top

Esito atteso: identificare i processi con CPU o memoria più alta. Se un processo resta in cima per parecchi secondi, non è un picco casuale.

Se vuoi una lettura più compatta sulla memoria:

free -h

Esito atteso: capire quanta memoria è realmente disponibile. Non fermarti alla colonna “used”, perché Linux usa la RAM anche per cache. Più utile guardare available. Se available è molto basso e lo swap cresce, il sistema sta entrando in pressione di memoria.

Per un controllo rapido dei processi più pesanti:

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 15

Esito atteso: vedere i primi 15 processi per CPU. Ripeti eventualmente ordinando per memoria con %mem per capire se il colpevole è diverso.

3. Capire se il collo di bottiglia è il disco

Molti rallentamenti non dipendono dalla CPU ma dall’I/O. Un server con CPU bassa può sembrare “bloccato” perché il disco è lento, una query pesa troppo o il filesystem è sotto pressione. Il segnale classico è questo: load alto, CPU non altissima e processi in stato di attesa I/O.

Per vedere rapidamente la situazione del disco:

iostat -xz 1 3

Se il comando non esiste, su Debian/Ubuntu installa il pacchetto sysstat; su Alma/Rocky/CentOS lo trovi nello stesso pacchetto. Esito atteso: individuare dischi con %util molto alto, tempi di attesa elevati o throughput anomalo.

Se non hai iostat, un controllo più grezzo ma utile è:

vmstat 1 5

Osserva le colonne wa e si/so. Se wa è alto, la CPU aspetta il disco. Se si e so crescono, c’è pressione di swap.

Un altro controllo spesso decisivo è vedere i processi in stato D, cioè in attesa non interrompibile su I/O:

ps -eo pid,stat,cmd | awk '$2 ~ /D/ {print}'

Esito atteso: se compaiono processi in stato D, il problema è molto probabilmente legato a disco, storage remoto, filesystem o storage layer del provider.

4. Individuare il processo responsabile

Quando hai confermato che il carico è reale, il passo successivo è isolare il processo responsabile. Non basta sapere che “MariaDB consuma”: devi capire quale query, quale tabella, quale job o quale servizio lo sta spingendo oltre il normale.

Per i processi attivi, usa:

top -o %CPU

oppure:

top -o %MEM

Esito atteso: il processo problematico appare in alto. Prendi nota di PID, comando completo e utente.

Se vuoi un elenco più stabile e facile da incollare in ticket o report:

ps -p <PID> -o pid,ppid,user,cmd,%cpu,%mem,lstart

Esito atteso: identificare chi ha avviato il processo, da quanto gira e quanto consuma.

Su server web, i casi più frequenti sono:

• php-fpm: script lenti, plugin difettosi, loop applicativi, richieste concorrenti eccessive.
• nginx/apache: traffico anomalo, bot aggressivi, configurazioni troppo permissive, file statici pesanti.
• mariadbd/mysqld: query lente, indici mancanti, tabelle grandi, lock, buffer insufficienti.
• redis-server: cache mal dimensionata o uso improprio come storage persistente.
• backup/compressione: job pianificati che saturano I/O e CPU in fascia critica.

5. Se il collo di bottiglia è PHP, database o web server

Per i siti web il vero problema è spesso uno di questi tre livelli: applicazione, web server o database. L’errore comune è riavviare il servizio senza capire quale livello sta generando la coda.

Se usi PHP-FPM, controlla prima lo stato del servizio:

systemctl status php*-fpm --no-pager

Esito atteso: vedere se il servizio è attivo, se ci sono restart continui o errori di pool. Se il servizio è in crash loop, non basta riavviarlo: bisogna leggere i log.

Log utili, a seconda della distribuzione:

journalctl -u php*-fpm -n 100 --no-pager

Per MariaDB/MySQL:

systemctl status mariadb --no-pager

e, se serve, i log di errore del database. Esito atteso: capire se ci sono lock, crash, errori di query o saturazione delle connessioni.

Per nginx o Apache:

systemctl status nginx --no-pager

systemctl status apache2 --no-pager

oppure su sistemi Red Hat:

systemctl status httpd --no-pager

Esito atteso: confermare se il server web è sano o se sta semplicemente subendo il sovraccarico di upstream PHP o database.

6. Leggere i log nel punto giusto

Quando un processo consuma troppo, il log quasi sempre spiega il motivo. Ma bisogna guardare il file corretto. Una lettura generica dei log di sistema spesso non basta.

Per i log recenti del sistema:

journalctl -xe --no-pager

Esito atteso: trovare errori rilevanti, OOM killer, problemi di filesystem, restart di servizi o messaggi di throttling.

Se sospetti memoria insufficiente, cerca l’OOM killer:

journalctl | grep -i -E 'oom|out of memory|killed process'

Esito atteso: capire se il kernel ha terminato processi per mancanza di RAM. In questo caso la causa non è il singolo crash, ma la pressione di memoria.

Se sospetti problemi del disco o filesystem, controlla anche:

dmesg -T | tail -n 50

Esito atteso: eventuali errori SATA, NVMe, ext4, XFS o timeouts di storage. Questo è uno dei controlli più importanti quando il server “si pianta” ma la CPU non è alta.

7. Correzioni sicure e reversibili

Una volta trovato il colpevole, evita interventi drastici. La correzione minima dipende dal tipo di processo, ma il principio resta lo stesso: ridurre la pressione senza rompere il servizio.

Se il processo è temporaneamente bloccato ma il servizio può restare attivo, puoi valutare un restart controllato del singolo servizio, non del server intero. Prima verifica che il processo sia davvero quello giusto e che un riavvio non causi perdita di dati o code critiche.

Esempi di intervento reversibile:

1. Riavvia solo il servizio coinvolto, ad esempio php-fpm, mariadb o nginx, e non l’intero sistema.
2. Riduci temporaneamente il traffico verso il sito con maintenance mode o rate limit se l’origine è un picco esterno.
3. Disattiva il job pianificato che sta saturando disco o CPU, se hai identificato un backup o una scansione pesante.
4. Riavvia il worker o il pool solo dopo aver salvato l’evidenza dei log.

Se vuoi fermare un processo manualmente, fallo con cautela. Prima prova un arresto gentile:

kill <PID>

Esito atteso: il processo termina in modo pulito. Se non risponde, solo dopo aver verificato l’impatto valuta un segnale più deciso. Evita di usare comandi aggressivi se non sei certo che il processo non stia gestendo operazioni critiche.

In caso di database saturo, controlla anche il numero di connessioni e le query lente. Un riavvio del database può mascherare il problema per pochi minuti e poi farlo tornare identico.

8. Se il problema è ricorrente, non fermarti al sintomo

Un server che si satura ogni giorno alla stessa ora non è “mal configurato e basta”: spesso esegue un’attività programmata o riceve traffico ripetitivo. Qui devi cercare il pattern.

Controlla:

• cron job e job di backup in fascia di punta.
• script PHP o Python che girano in loop.
• query lente ripetute da applicazioni o plugin.
• bot, crawler o traffico anomalo.
• limiti troppo stretti di PHP-FPM o del database.

Se il problema è un sito WordPress, i sospetti principali sono plugin pesanti, query non indicizzate, wp-cron troppo frequente e cache assente o mal dimensionata. Se invece il carico è sul database, spesso il fix reale è aggiungere indici, ridurre il numero di query per pagina o correggere il plugin che genera richieste inutili.

9. Controlli finali dopo il fix

Dopo ogni intervento, non fidarti della sensazione: verifica numeri e log. I controlli minimi da rifare sono questi:

1. uptime per vedere se il load è rientrato.
2. top o ps per confermare che il processo anomalo non sia più in cima.
3. free -h per verificare che la RAM sia tornata disponibile e lo swap non stia salendo.
4. iostat -xz 1 3 o vmstat 1 5 per confermare che il disco non sia più saturo.
5. I log del servizio coinvolto per verificare che non compaiano nuovi errori.

Se il problema si ripresenta dopo poco, il rollback più sicuro è tornare alla configurazione precedente, riattivare il servizio solo se necessario e raccogliere più evidenze prima di fare altre modifiche. Questo vale soprattutto per cambi a PHP-FPM, database, cache o limiti di connessione.

Principio utile: non ottimizzare “a sensazione”. Prima misura il collo di bottiglia, poi intervieni sul singolo strato che lo genera.

10. Checklist operativa rapida

• Controlla se il problema è CPU, RAM o disco, non tutti insieme a caso.
• Identifica il PID o il servizio che consuma di più.
• Leggi i log del componente coinvolto prima di riavviarlo.
• Applica solo un fix reversibile e verifica subito l’effetto.
• Se il guasto torna, cerca il pattern cronologico e la causa applicativa.

Assunzione: i comandi sono eseguiti con privilegi adeguati e su sistemi Linux standard con systemd.

Conclusione pratica

La diagnosi corretta di un server lento su Linux non parte dal “riavvio di tutto”, ma dalla lettura ordinata delle risorse. CPU, RAM, swap e I/O raccontano storie diverse, e solo incrociandole con i log puoi capire se il problema sta nel web server, nel database, in PHP o nello storage. Più il fix è mirato, più è facile verificare il risultato e soprattutto evitare regressioni.

Se costruisci l’abitudine di controllare prima i numeri e poi i servizi, in pochi minuti riesci spesso a distinguere un picco passeggero da un guasto vero. Ed è lì che si fa la differenza tra “server che sembra rotto” e “collo di bottiglia individuato”.