Linux: controlli rapidi quando il disco I/O rallenta il server

Quando il server è lento ma CPU e RAM non spiegano tutto

Capita spesso di vedere un Linux “pesante” senza un motivo evidente: i processi non sembrano saturare la CPU, la memoria è ancora disponibile, ma tutto risponde con ritardo. In questi casi il sospetto più utile non è il carico generico, ma il disco. Più precisamente: I/O disk bound, cioè il sistema aspetta il disco più di quanto stia davvero calcolando.

È un problema tipico su VPS, server condivisi, macchine con storage lento, database sotto stress, backup avviati nel momento sbagliato, log troppo verbosi o filesystem quasi pieno. Non serve partire da diagnosi complicate: conviene fare pochi controlli mirati, capire se il collo di bottiglia è davvero il disco e poi intervenire con un fix reversibile.

Segnali pratici da non ignorare

Prima ancora dei comandi, osserva i sintomi. Se il problema è davvero legato al disco, di solito compaiono uno o più di questi segnali:

• il sito o il servizio “si impunta” a tratti, anche se non va in errore;
• i tempi di risposta aumentano soprattutto durante backup, import, aggiornamenti o picchi di traffico;
• comandi semplici come ls, df o systemctl status sembrano lenti;
• nel monitoraggio vedi CPU bassa o media, ma il server resta comunque reattivo a singhiozzo;
• la latenza aumenta quando il database lavora o quando scrive molti log.

Se invece la CPU è costantemente al 100%, il problema potrebbe essere diverso. Se la RAM finisce e il sistema swappa pesantemente, il disco rallenta come conseguenza. Per questo la diagnosi corretta parte sempre da un controllo incrociato.

Controlli rapidi per capire se il collo di bottiglia è il disco

I controlli qui sotto sono pensati per essere rapidi, poco invasivi e utili anche su server in produzione.

1. Verifica il carico reale del sistema

Il primo comando da usare è uptime, perché mostra il load average, cioè quanta pressione c’è sul sistema in quel momento.

uptime

Esito atteso: se il load average è alto ma CPU e RAM non sono saturi, spesso c’è attesa I/O. Su molti server, un carico molto più alto del numero di core richiede un approfondimento.

Per un quadro migliore, usa anche:

top

Esito atteso: osserva la riga con wa o iowait. Se è alta, la CPU sta aspettando il disco. In pratica il processore non è il vero problema: sta fermo in coda.

2. Controlla se il disco è saturo di attese

Lo strumento più utile, quando disponibile, è iostat dal pacchetto sysstat.

iostat -xz 1 3

Esito atteso: cerca valori elevati in %util, await e svctm non affidabile su alcuni sistemi, oltre a letture/scritture lente. Se %util resta vicino al 100% e i tempi di attesa sono alti, il disco è molto probabilmente il collo di bottiglia.

Se iostat non è installato, su Debian/Ubuntu puoi aggiungerlo con:

sudo apt update && sudo apt install sysstat

Su Alma/Rocky/CentOS:

sudo dnf install sysstat

Nota: installare sysstat è sicuro e reversibile, ma fallo solo se hai i permessi e preferibilmente in una finestra di bassa attività.

3. Identifica il processo che sta scrivendo o leggendo troppo

Se il disco è sotto pressione, devi capire chi lo sta stressando. Usa:

sudo iotop -oPa

Esito atteso: emergono processi con letture/scritture importanti, ad esempio database, backup, compressioni, antivirus, logrotate, cron o applicazioni che fanno import massivi.

Se iotop non è disponibile, installalo con:

sudo apt install iotop

oppure:

sudo dnf install iotop

Se non vuoi installare nulla, puoi usare anche:

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

Non misura l’I/O, ma aiuta a vedere se un processo pesante coincide col rallentamento.

4. Verifica spazio libero e inode

Un disco quasi pieno può peggiorare molto le prestazioni, soprattutto su filesystem con tanti file piccoli o database.

df -h

Esito atteso: le partizioni non dovrebbero stare stabilmente oltre l’85-90% se il server lavora con molti file o con database attivi.

Controlla anche gli inode:

df -i

Esito atteso: se gli inode sono esauriti, non puoi creare nuovi file anche se lo spazio sembra ancora disponibile. Questo succede spesso con cache, maildir e directory piene di file piccoli.

5. Cerca errori del kernel o del filesystem

Quando il disco rallenta in modo anomalo, il problema potrebbe non essere solo “carico”, ma anche errori reali di storage.

dmesg -T | tail -n 50

Esito atteso: nessun errore I/O, nessun reset del device, nessun timeout del filesystem, nessun messaggio di blocco del kernel. Se compaiono errori ripetuti, non si tratta più di semplice lentezza: serve prudenza.

Cause più comuni del rallentamento I/O

Una volta confermato che il disco è coinvolto, la causa di solito rientra in pochi casi concreti.

Backup avviati nelle ore sbagliate

Il caso classico è il backup giornaliero che parte mentre il sito è ancora attivo. Se comprime molti file o salva database grandi, il disco si satura e tutto il resto aspetta.

Controllo utile: verifica i cron, i job del pannello hosting e gli script automatici. Su Plesk, cPanel o FastPanel controlla le attività pianificate e l’orario di esecuzione.

Database con query lente o troppe scritture

MySQL/MariaDB può saturare l’I/O con query non ottimizzate, tabelle grandi, indici mancanti o import massivi. In questo caso il server non è “rotto”: sta semplicemente aspettando troppe operazioni su disco.

Controllo utile: se il problema coincide con il database, abilita o consulta lo slow query log e verifica se i tempi di risposta peggiorano in modo coerente.

Log troppo verbosi

Un’applicazione che scrive log a raffica può sembrare innocua, ma alla lunga riempie il disco e genera molte scritture piccole. Anche il web server, il mail server e il sistema di sicurezza possono produrre volumi importanti di log.

Controllo utile: osserva directory come /var/log, i log del web server e quelli dell’applicazione. Se crescono troppo in fretta, il problema è immediato.

Storage lento o VPS con I/O limitato

Su alcuni ambienti virtualizzati il collo di bottiglia non dipende da te: il provider può applicare limiti di IOPS o condividere lo storage con altri tenant. In questo caso il server sembra “normale”, ma il disco resta il punto debole.

Controllo utile: confronta il comportamento in orari diversi. Se il rallentamento compare soprattutto nelle fasce di punta, il problema può essere infrastrutturale.

Soluzione consigliata: intervenire senza peggiorare la situazione

Quando la causa è chiara, la regola è semplice: prima riduci la pressione, poi ottimizza. Evita interventi pesanti a caso.

1. Sposta o riduci i carichi non urgenti

Se trovi backup, import, compressioni o task pianificati, rimandali fuori fascia. È l’intervento più sicuro perché non altera l’applicazione, ma toglie pressione al disco.

Verifica successiva: rilancia iostat -xz 1 3 o controlla il sito dopo aver fermato il job. Se la latenza scende, hai trovato il colpevole o almeno un fattore importante.

2. Riduci la produzione di log inutili

Se un servizio scrive troppo, abbassa il livello di logging solo se sai cosa stai facendo e se puoi tornare indietro facilmente. In parallelo, abilita una rotazione log corretta, così i file non crescono senza controllo.

Verifica successiva: controlla che la crescita dei log rallenti e che il disco recuperi respiro nei minuti successivi.

3. Ottimizza il database se è lui a spingere il disco

Se il database è il responsabile, il fix più utile non è “riavviare e sperare”, ma capire quali query fanno danno. Cerca query lente, indici mancanti, tabelle eccessivamente grandi o import ripetuti.

Verifica successiva: dopo l’ottimizzazione, confronta tempi di risposta e uso I/O. Se il sito torna reattivo ma il disco resta alto solo nei picchi, la causa è stata almeno ridotta.

4. Libera spazio in modo ordinato

Se df -h mostra una partizione quasi piena, libera spazio con criterio: vecchi backup, log obsoleti, cache non necessarie e file temporanei. Non cancellare a caso directory di sistema o dati applicativi senza sapere cosa contengono.

Verifica successiva: lo spazio libero deve salire in modo visibile e il sistema dovrebbe smettere di degradare sotto carico.

5. Se il disco mostra errori, tratta il caso come incidente

Se dmesg segnala errori I/O, reset del device o filesystem in read-only, non fare tuning: fai stabilizzazione. In questo scenario la priorità è proteggere i dati e verificare backup recenti.

Verifica successiva: controlla integrità del servizio, backup e stato dello storage prima di qualsiasi riavvio non necessario.

Come distinguere un vero problema disco da un sintomo secondario

Non tutti i rallentamenti con “disco coinvolto” nascono dal disco stesso. A volte il disco è solo l’effetto finale di un’altra causa.

• RAM insufficiente: se il sistema swappa molto, il disco lavora di più perché la memoria non basta.
• CPU bloccata da un processo: il disco sembra lento ma in realtà un servizio monopolizza il sistema.
• Picco applicativo: un deploy, una cache svuotata o un import possono generare scritture anomale e temporanee.
• Database mal ottimizzato: le query lente producono letture continue, non sempre visibili a colpo d’occhio.

Per questo conviene sempre incrociare almeno tre dati: uptime o top, iostat e df -h. Solo così distingui il vero problema dal sintomo.

Esempio pratico di lettura dei risultati

Immagina questo scenario: il sito risponde lentamente, il load average è alto, ma la CPU non supera il 20%. In top vedi wa sopra il normale, in iostat -xz 1 3 il disco mostra utilizzo quasi pieno e tempi di attesa alti, mentre iotop evidenzia un backup notturno ancora in corso. In quel caso la diagnosi è molto probabile: non serve cambiare stack o reinstallare nulla, basta fermare o riprogrammare il job.

Altro scenario: df -h mostra la partizione al 95%, i log crescono di ore in ore, e il database scrive tanto. Qui il fix minimo è liberare spazio, ridurre i log e verificare il comportamento dopo l’intervento. Se invece compaiono errori nel kernel, la priorità diventa il recupero dello storage.

Buone pratiche per non ritrovarsi nel problema

La prevenzione è molto più semplice della correzione a caldo. Alcune abitudini evitano gran parte dei rallentamenti da I/O:

• programma backup e rotazioni log in fasce a basso traffico;
• monitora spazio disco, inode e latenza I/O con alert chiari;
• tieni il filesystem con margine, non vicino al limite;
• ottimizza il database prima che cresca troppo;
• evita processi che scrivono file temporanei senza pulizia;
• se usi VPS, controlla i limiti di storage previsti dal provider.

In ambito hosting, una buona regola pratica è questa: quando il server “sembra lento”, non fermarti alla CPU. Il disco è spesso il colpevole silenzioso, soprattutto nei sistemi con molti file, CMS dinamici, email e database attivi.

Checklist finale rapida

• Controlla uptime e top per capire se c’è attesa I/O.
• Esegui iostat -xz 1 3 per verificare saturazione e latenza del disco.
• Usa iotop -oPa per trovare il processo che scrive o legge troppo.
• Controlla df -h e df -i per spazio e inode.
• Leggi dmesg -T | tail -n 50 per escludere errori di storage.

Se vuoi un’unica regola da tenere a mente: prima misura, poi alleggerisci il carico, infine ottimizza. Con il disco, intervenire alla cieca costa tempo e spesso peggiora la situazione.