Linux: capire perché un server web risponde lento o va in timeout

Perché questa diagnosi va fatta in ordine

Quando un server web diventa lento, la tentazione è riavviare tutto. È quasi sempre il modo più veloce per perdere indizi utili e risolvere solo per pochi minuti. La strada migliore è più semplice: capire quale livello sta rallentando la risposta, distinguere tra problema di rete, web server, PHP, database, disco o risorse della macchina.

Un server che risponde in ritardo non è sempre “sotto carico”. A volte sta aspettando un database lento, una coda di PHP-FPM piena, un disco in sofferenza, una cache assente o un backend esterno che non risponde. La diagnosi efficace parte da ciò che si vede dall’esterno e scende a strati, fermandosi appena si trova il collo di bottiglia.

Il metodo più utile: osservare il percorso della richiesta

Una richiesta web attraversa più punti: DNS, connessione TCP, eventuale TLS, web server, interprete PHP o altro runtime, database, filesystem e servizi esterni. Se il tempo totale è alto, il problema è quasi sempre in uno di questi passaggi.

Per questo conviene lavorare così:

1. verificare se il sito è lento sempre o solo in alcune pagine;
2. misurare dove si perde tempo: connessione, TTFB, risposta applicativa;
3. controllare i log del web server e del PHP;
4. guardare CPU, RAM, I/O disco e saturazione delle code;
5. solo dopo intervenire con il fix minimo e reversibile.

Controlli rapidi dall’esterno

Se il sito è pubblico, il primo passo è misurare il comportamento dalla rete, non dal pannello del server. Così separi il problema lato client da quello lato host.

curl -o /dev/null -s -w 'DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}
' https://tuodominio.tld/

Se il valore che cresce è TTFB, il ritardo è quasi sempre lato server o applicazione. Se cresce soprattutto DNS o TCP, il problema è prima della generazione della pagina.

Per capire se il rallentamento è generale o riguarda solo una pagina, testa almeno:

• la home page;
• una pagina statica;
• una pagina dinamica con login, form o query al database.

Se la pagina statica risponde veloce e quella dinamica no, il problema non è il web server in sé: è più probabilmente PHP, database o un plugin/applicazione.

Verificare il web server senza fare danni

Su Apache o Nginx il sintomo più comune è un aumento delle richieste in coda, worker saturi o timeout verso PHP-FPM. I log sono la fonte più utile, perché spesso dicono già dove guardare.

Controlla gli errori recenti del web server:

sudo tail -n 100 /var/log/nginx/error.log

sudo tail -n 100 /var/log/apache2/error.log

Segnali tipici da cercare:

• upstream timed out: Nginx aspetta troppo da PHP o da un backend;
• AH00161 o errori simili: Apache ha saturazione o problemi di backend;
• connect() failed: backend non raggiungibile;
• too many open files: limite di file descriptor troppo basso;
• client intended to send too large body: problema diverso, ma spesso confuso con lentezza.

Se i log mostrano timeout verso PHP-FPM, il web server sta probabilmente aspettando un pool PHP pieno o bloccato. In questo caso il problema è a valle, non nel front-end.

Controllare PHP-FPM: la causa più frequente nei siti dinamici

Molti siti WordPress, CMS o app PHP diventano lenti perché PHP-FPM non riesce a servire abbastanza richieste contemporanee. Quando i worker sono tutti occupati, le nuove richieste restano in coda o vanno in timeout.

Controlli utili:

sudo systemctl status php*-fpm --no-pager

sudo tail -n 100 /var/log/php*-fpm.log

Se non conosci il file esatto, cerca i pool e i log attivi con:

sudo grep -R "slowlog\|pm.max_children\|listen.backlog" /etc/php* /etc/*fpm* 2>/dev/null

Segnali da interpretare:

• server reached pm.max_children: il pool è troppo piccolo o il codice è lento;
• child exited on signal 9: possibile OOM killer o consumo eccessivo;
• pool seems busy: richieste bloccate o troppo lente;
• slowlog: utile per individuare script che impiegano troppo tempo.

Se hai accesso al pannello, nei sistemi con cPanel, Plesk o FastPanel conviene controllare lo stato dei processi PHP, i limiti del pool e gli eventuali slow log direttamente dall’interfaccia, perché spesso la configurazione è distribuita su più vhost o versioni PHP.

Capire se il database è il collo di bottiglia

Quando la pagina resta in attesa ma il web server non mostra errori evidenti, il database è uno dei sospetti principali. Query lente, indici mancanti, lock o connessioni esaurite possono bloccare l’intera applicazione.

Verifiche minime:

sudo systemctl status mysql --no-pager

sudo systemctl status mariadb --no-pager

mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_running'; SHOW GLOBAL STATUS LIKE 'Connections';"

Se Threads_running è alto in modo anomalo o il numero di connessioni cresce senza scendere, il database sta soffrendo. In quel caso controlla anche i log errori:

sudo tail -n 100 /var/log/mysql/error.log

sudo tail -n 100 /var/log/mariadb/mariadb.log

Segnali tipici:

• query lente ripetute;
• lock su tabelle o righe;
• buffer troppo piccoli o cache inefficiente;
• spike improvvisi dovuti a cron, import, backup o bot.

Se l’applicazione usa WordPress, il problema spesso è un plugin che fa troppe query, una tabella senza indice o un oggetto cache mancante. Se possibile, attiva il log delle query lente solo per la durata della diagnosi, poi disattivalo per evitare rumore e overhead.

Il disco lento è un problema sottovalutato

Un server con CPU bassa ma disco molto occupato può sembrare “strano” perché i processi non risultano saturi, eppure tutto risponde in ritardo. Questo accade spesso su VPS con storage condiviso, backup in corso, log enormi o database che fanno molto I/O.

Controlli rapidi:

iostat -xz 1 5

df -h

sudo du -sh /var/log/* 2>/dev/null | sort -h

Se %util è alto e await cresce, il disco è in saturazione o il backend storage è lento. Se la partizione è quasi piena, il filesystem può degradare sensibilmente, specialmente con database e log attivi.

Attenzione anche alle operazioni di manutenzione: compressione, rotazione log, backup, scansioni antivirus o indicizzazioni possono creare picchi di I/O e far sembrare il server “bloccato” per alcuni minuti.

CPU e RAM: capire quando il problema è la capacità reale

Non sempre il server è lento per un bug. A volte è semplicemente sottodimensionato. Se la CPU è sempre alta e la RAM è esaurita, il sistema inizia a fare swap e ogni richiesta diventa più costosa.

Controlli utili:

top

free -h

vmstat 1 5

Segnali da leggere:

• si/so alti in vmstat: swap in uso, quindi possibile degrado forte;
• RAM quasi tutta occupata e cache assente: rischio di OOM o rallentamenti;
• CPU alta ma un solo processo dominante: codice o query inefficienti;
• CPU alta su più core e molte richieste: carico reale o attacco di traffico.

Se il sistema ha poca memoria, spesso il fix non è “riavviare”, ma ridurre i worker, ottimizzare il pool PHP, abbassare il consumo del database o aggiungere RAM. Il riavvio può solo mascherare il problema finché il traffico non torna.

Quando il problema è l’applicazione e non l’infrastruttura

Se web server, PHP, database, CPU, RAM e disco sembrano sani ma il sito continua a essere lento, il problema è spesso nel codice o in una dipendenza esterna.

Gli indizi più comuni sono:

• una singola pagina molto più lenta delle altre;
• latenza concentrata su login, carrello, checkout o ricerca;
• chiamate a API esterne che non rispondono;
• plugin o moduli appena aggiornati;
• cron job che partono in orari precisi e saturano il server.

In questi casi conviene fare un test di esclusione: disattivare temporaneamente il plugin sospetto, cambiare tema, bypassare un proxy applicativo o disabilitare un cron non essenziale. La regola è semplice: cambia una sola variabile per volta e verifica subito l’effetto.

Se usi cPanel, Plesk o FastPanel

Nei pannelli hosting, gran parte della diagnosi si può fare senza terminale. È spesso la via più sicura per chi gestisce più siti o non vuole toccare file di configurazione a mano.

In cPanel

• controlla Metrics per errori e statistiche di traffico;
• usa Errors per vedere gli ultimi errori PHP o CGI;
• verifica la versione PHP e i moduli da Select PHP Version o strumenti equivalenti;
• se disponibile, apri PHP-FPM o MultiPHP Manager per controllare limiti e pool.

In Plesk

• vai su Websites & Domains e apri Logs;
• controlla il settaggio PHP del dominio;
• verifica se il sito usa cache integrata o proxy;
• usa le statistiche del dominio per vedere picchi e errori ricorrenti.

In FastPanel

• controlla i log del sito dalla scheda del dominio;
• verifica lo stato di Nginx, PHP-FPM e database nel pannello servizi;
• se un sito singolo è lento, confrontalo con altri siti sulla stessa macchina per capire se è un problema globale o locale.

Se il pannello mostra un singolo sito problematico mentre gli altri sono veloci, la causa è quasi sempre nella configurazione del vhost, nel codice o nei limiti PHP assegnati a quel dominio.

Fix minimi e reversibili che spesso risolvono

La correzione migliore è quella più piccola che elimina il collo di bottiglia senza introdurre effetti collaterali.

1. Riavvia solo il servizio bloccato, non l’intera macchina. Se i log indicano PHP-FPM in sofferenza, riavvia solo quel servizio e poi verifica il TTFB. Il risultato atteso è un recupero immediato dei tempi di risposta senza impattare gli altri servizi.
2. Aumenta i limiti con cautela. Se il pool PHP arriva spesso a pm.max_children, valuta un incremento moderato e misurato. Il successo si vede se spariscono i timeout e non cresce lo swap.
3. Attiva o migliora la cache. Cache di pagina, object cache o opcode cache possono abbattere drasticamente il TTFB. L’obiettivo è ridurre il lavoro per ogni richiesta, non coprire il problema.
4. Ottimizza il database. Se esistono query lente, aggiungi gli indici mancanti o correggi la query più costosa. Il controllo successivo è la riduzione del tempo medio di risposta nelle pagine che interrogano il DB.
5. Riduci il rumore. Disabilita temporaneamente cron pesanti, backup in orari di punta o job di manutenzione che coincidono con i picchi.

Come verificare che la correzione funzioni davvero

Dopo ogni intervento, non fidarti della sensazione. Ripeti sempre gli stessi test che hai usato per misurare il problema.

curl -o /dev/null -s -w 'TTFB:%{time_starttransfer} TOTAL:%{time_total}
' https://tuodominio.tld/

Confronta il valore prima e dopo il fix. Se il TTFB scende ma il totale resta alto, il collo di bottiglia potrebbe essere ancora in una dipendenza esterna o nella rete. Se scendono entrambi, il fix è stato efficace.

Rileggi anche i log nelle 10-15 minuti successive. Il successo non è solo “adesso va”: è nessun nuovo timeout, nessun errore ripetuto e nessun picco anomalo di CPU, RAM o I/O.

Quando serve il rollback

Ogni modifica di tuning va trattata come reversibile. Se dopo il cambio peggiora la situazione, torna alla configurazione precedente invece di aggiungere ulteriori ritocchi.

Rollback tipici:

• ripristinare il valore originale di pm.max_children o altri parametri del pool PHP;
• disattivare temporaneamente una cache appena introdotta, se genera inconsistenze;
• tornare alla versione precedente di un plugin o modulo appena aggiornato;
• ripristinare i limiti del database se un aumento aggressivo ha portato il server in swap.

La regola pratica è semplice: se un cambio non migliora entro poco tempo e i log peggiorano, si annulla subito e si passa al sospetto successivo.

Checklist finale operativa

• Misura il problema con curl e distingui DNS, connessione e TTFB.
• Controlla i log di web server, PHP e database prima di riavviare qualunque servizio.
• Verifica CPU, RAM e I/O per capire se il limite è infrastrutturale.
• Intervieni con un fix minimo, poi ripeti gli stessi test iniziali.
• Se peggiora, fai rollback della sola modifica introdotta.

Assunzione: il server ospita uno o più siti dinamici su stack Linux con Apache o Nginx, PHP-FPM e database MySQL/MariaDB.