Linux: capire perché il server è lento senza fermarlo

Quando un server “va piano”, il problema quasi mai è uno solo

La lentezza su Linux è spesso un effetto combinato: un processo che consuma CPU, una memoria quasi esaurita, un disco in coda, una rete instabile o un servizio bloccato in attesa di risposte. Il punto non è guardare “quanto è alto il carico”, ma capire quale risorsa è davvero satura e quale processo la sta usando.

Questa guida segue un principio semplice: prima misuro, poi tocco. È il modo più sicuro per intervenire su un VPS, un server dedicato o un hosting con servizi critici in produzione.

1. Parti dalla fotografia generale

Prima di aprire log e processi, fai un controllo rapido dello stato del sistema. In pochi secondi ottieni il quadro iniziale e capisci dove andare a cercare.

uptime
free -h
df -hT

Questi tre comandi ti dicono:

• uptime: carico medio e tempo di attività del server.
• free -h: memoria usata, libera, cache e swap.
• df -hT: spazio disco e tipo di filesystem montato.

Se vedi RAM quasi piena e swap in uso, la lentezza può dipendere dalla memoria. Se il disco è al 90-100%, il sistema può rallentare anche senza un CPU elevato. Se il carico è alto ma la CPU non è al massimo, spesso il collo di bottiglia è I/O disco o attesa di rete.

2. Capisci se il problema è CPU, memoria o I/O

La schermata più utile è quella che mostra i processi in tempo reale. Su quasi tutte le distribuzioni trovi top installato di default; in alternativa, se disponibile, htop è più leggibile.

top

Osserva questi elementi:

• %us e %sy: CPU consumata da utente e kernel.
• %id: CPU inattiva; se è bassa, la macchina è sotto pressione.
• %wa: attesa I/O; se cresce, il disco o lo storage stanno rallentando tutto.
• load average: utile solo se confrontato con il numero di core e con i processi in attesa.

Se vuoi una lettura più chiara dei processi, usa:

ps -eo pid,ppid,user,%cpu,%mem,stat,comm --sort=-%cpu | head -15
ps -eo pid,ppid,user,%cpu,%mem,stat,comm --sort=-%mem | head -15

Il primo elenco mostra chi sta consumando più CPU, il secondo chi occupa più RAM. La colonna STAT aiuta a vedere se un processo è in stato di sleep, stop o attesa.

3. Controlla la memoria prima di accusare la CPU

Molti server sembrano “lenti” perché non hanno più memoria libera e iniziano a usare swap. In quel caso il sistema continua a funzionare, ma con un degrado molto evidente.

free -h
vmstat 1 5

Con vmstat osserva in particolare:

• si/so: swap in ingresso e uscita; se sono costanti, la memoria è in sofferenza.
• r: processi in coda per la CPU.
• wa: attesa I/O.

Se la swap cresce e non scende, il sistema sta compensando una carenza di RAM o un processo ha un comportamento anomalo. In un server web, spesso il colpevole è PHP-FPM, MariaDB/MySQL, un job batch o un processo di importazione.

Regola pratica: se la RAM è quasi piena ma la cache è alta, non è automaticamente un problema. Se invece la swap è attiva e cresce, la lentezza è molto più probabile.

4. Verifica il disco: spesso è lui il vero collo di bottiglia

Un server con CPU bassa ma risposta lenta spesso soffre di I/O. Questo succede con dischi saturi, storage remoto, VM rumorose o database che fanno molte letture casuali.

iostat -xz 1 5

Se il comando non esiste, su Debian/Ubuntu e RHEL-like può arrivare dal pacchetto sysstat. I valori da leggere sono:

• %util vicino al 100%: il disco è saturo.
• await elevato: i processi aspettano troppo le operazioni disco.
• r/s e w/s: letture e scritture al secondo.

Puoi anche usare:

iotop -oPa

Questo mostra i processi che stanno realmente usando il disco. È molto utile per distinguere tra un database, un backup, un log rotato male o un crawler che ha iniziato a scrivere troppo.

Se iotop non è disponibile, una verifica alternativa è:

sudo lsof +L1

Questo comando evidenzia file eliminati ma ancora aperti da qualche processo. Succede spesso con log ruotati male o servizi che tengono occupato spazio disco pur sembrando cancellato.

5. Identifica i processi che hanno superato il limite “sano”

Una volta capito il tipo di saturazione, devi associare la lentezza al processo giusto. Cerca prima i servizi più probabili: web server, database, PHP, mail, backup, agent di monitoraggio, antivirus, compressione o import/export.

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

Se il server ospita siti web, verifica in particolare:

• php-fpm, lsphp o php-cgi per il lato applicativo.
• mysqld o mariadbd per il database.
• nginx o httpd/apache2 per il web server.
• rsync, tar, gzip, pigz per backup e archiviazione.

Se trovi un processo con tempo di esecuzione molto lungo e consumo costante, non lo terminare subito: prima verifica se è un job legittimo, un backup o una manutenzione pianificata.

6. Leggi i log nel punto giusto, non a caso

I log servono a confermare l’ipotesi, non a sostituire la diagnosi. Cerca gli errori più vicini all’orario in cui il server ha iniziato a rallentare.

journalctl -p 3 -xb
journalctl --since "1 hour ago"

Il primo mostra gli errori gravi del boot corrente, il secondo gli eventi recenti. Se il problema è un servizio specifico, filtra il suo nome:

journalctl -u nginx --since "1 hour ago"
journalctl -u mariadb --since "1 hour ago"
journalctl -u php8.2-fpm --since "1 hour ago"

Su sistemi con log file classici, controlla anche:

tail -n 100 /var/log/syslog
tail -n 100 /var/log/messages
tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/httpd/error_log

Se vedi messaggi di timeout, kill per OOM, errori di connessione al database o crash ripetuti, hai già una pista affidabile.

7. Cerca i segnali di OOM, swap e processi uccisi dal kernel

Quando la memoria finisce, Linux può attivare l’OOM killer e terminare i processi più pesanti. Il sintomo esterno è un sito lento o una pagina bianca; il sintomo interno è un processo sparito o riavviato.

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

Se trovi righe di questo tipo, il problema non è “solo lentezza”: è saturazione memoria con intervento del kernel. In questo caso va capito quale servizio consuma troppo e perché. Su server web il colpevole è spesso una combinazione di picchi PHP, query lente e cache assente.

8. Controlla la rete solo se CPU, RAM e disco non spiegano il problema

La rete è meno spesso la causa principale, ma quando lo è il sintomo è chiaro: richieste lente, timeout, connessioni fallite, ma risorse locali non sature.

ss -s
ip -s link
ping -c 4 8.8.8.8

ss -s mostra lo stato generale delle socket. ip -s link aiuta a vedere errori e drop sull’interfaccia. Un ping verso un IP esterno non dice tutto, ma serve a verificare se la connettività base è stabile.

Se il server è dietro proxy, CDN o bilanciamento, controlla anche i log del front-end. A volte il problema non è il server, ma il numero di connessioni in ingresso o un upstream lento.

9. Se il problema è un sito web, concentra la diagnosi su tre punti

Su un sito lento, la lentezza percepita nasce quasi sempre da una di queste tre aree: web server, PHP o database. La diagnosi più rapida è seguire il percorso della richiesta.

• Web server: errori di configurazione, worker saturi, coda di richieste.
• PHP: processi bloccati, memory limit insufficiente, plugin pesanti.
• Database: query lente, lock, connessioni esaurite, buffer troppo piccoli.

Per il database, una verifica rapida utile è:

mysqladmin proc status

Se hai accesso al database, controlla anche le query lente. In MariaDB/MySQL il log delle query lente è spesso il modo più rapido per trovare il punto esatto del rallentamento.

10. Intervieni con la modifica minima, non con il riavvio immediato

Il riavvio “risolve” solo se il problema è transitorio. Se lo fai senza capire la causa, il server tornerà lento dopo poco. La prima correzione deve essere minima e reversibile.

1. Se un processo è palesemente fuori controllo, valuta un restart del solo servizio, non dell’intero server.
2. Se il disco è pieno, libera spazio in modo selettivo: log, backup vecchi, cache temporanee, file scartati.
3. Se la RAM è satura, riduci il carico applicativo, limita i worker o disattiva temporaneamente un job non essenziale.
4. Se il database è il collo di bottiglia, identifica query lente e lock prima di cambiare i parametri globali.

Per riavviare un servizio in modo controllato, usa il nome preciso del demone e verifica subito dopo lo stato:

sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

Il controllo successivo deve mostrare il servizio attivo e senza errori recenti. Fai lo stesso con database, PHP-FPM o altri componenti coinvolti.

11. Evita gli errori classici che fanno perdere tempo

Quando un server è lento, i falsi positivi sono frequenti. Alcuni errori tipici da evitare:

• guardare solo la CPU e ignorare la colonna %wa.
• confondere RAM piena con RAM realmente esaurita, senza leggere cache e swap.
• riavviare il server prima di avere un log o un processo sospetto da verificare.
• cancellare file di log o temporanei senza capire quale servizio li stia generando.
• toccare parametri di MySQL, PHP o kernel senza una misura precedente.

La lentezza è quasi sempre un sintomo, non la causa. Se modifichi il sintomo senza correggere il motore del problema, il guasto torna.

12. Metodo rapido da usare ogni volta

Se vuoi una procedura semplice da ripetere su ogni server, usa questo ordine:

1. Fotografia generale: carico, RAM, disco.
2. Identificazione del collo di bottiglia: CPU, memoria, I/O o rete.
3. Processo responsabile: top, ps, iotop.
4. Conferma nei log: journalctl e log applicativi.
5. Fix minimo: solo il servizio o la risorsa coinvolta.
6. Verifica finale: stesso controllo iniziale, ma dopo l’intervento.

Questo approccio è più veloce di qualsiasi tentativo “a intuito” e riduce il rischio di peggiorare la situazione in produzione.

13. Esempio pratico di lettura del problema

Immagina questo scenario: il sito risponde lentamente, ma la CPU non è al 100%. free -h mostra swap in uso, vmstat segnala swap attiva, e iotop evidenzia un backup in corso. In questo caso il problema non è il web server: è il backup che sta saturando disco e memoria.

Altro scenario: CPU alta, RAM normale, disco non saturo, ma ps mostra un processo PHP-FPM con molti worker e il log del sito riporta richieste lente verso il database. Qui il collo di bottiglia è probabilmente applicativo, con query lente o plugin pesanti.

Terzo scenario: disco con %util altissimo e await elevato, mentre mysqld è in cima ai processi. In questo caso il database sta generando un I/O intenso e il resto del server resta in coda.

14. Un set minimo di comandi da tenere pronto

Se devi lavorare velocemente, questi sono i controlli essenziali da memorizzare:

uptime
free -h
df -hT
top
ps -eo pid,user,comm,%cpu,%mem,etime --sort=-%cpu | head -20
vmstat 1 5
journalctl -p 3 -xb

Con questi comandi copri il 90% dei casi di lentezza “generica” su Linux. Il resto si risolve quasi sempre entrando nel servizio specifico: web, database, PHP, mail, backup o storage.

Conclusione operativa

Il modo corretto di diagnosticare un server lento è sempre lo stesso: misura, isola, conferma, intervieni. Non serve partire dal riavvio né cambiare mille parametri insieme. Serve capire se il limite è CPU, RAM, disco o rete, e poi verificare quale servizio lo sta causando.

Se lavori con siti web o VPS in produzione, questa disciplina fa davvero la differenza: riduce il downtime, evita fix inutili e porta al punto giusto più in fretta. Un server lento non è un mistero: è quasi sempre un segnale leggibile, purché lo si osservi nel posto giusto.