Il sintomo che inganna: load average alto, CPU quasi fermaCapita spesso a chi gestisce server #Linux in produzione: il monitoraggio segnala un load average sopra 30 su una macchina con 24 core, gli utenti si lamentano di risposte lente, ma top mostra la #CPU idle al 70%. Il riflesso istintivo è cercare il processo che “mangia CPU”, ma qui il colpevole non c’è da nessuna parte nella lista dei consumi di calcolo: il collo di bottiglia è l’I/O su disco, e la differenza tra i due scenari cambia completamente la strategia di intervento.
Il load average di Linux non misura solo i processi che vogliono la CPU: conta anche quelli bloccati in stato D (uninterruptible sleep), cioè in attesa che il #kernel completi un’operazione di I/O. Un load di 30 con CPU libera significa quasi sempre che decine di thread sono in coda per il disco, non per il processore. Diagnosticare questo scenario richiede un metodo diverso da quello usato per un semplice sovraccarico di calcolo, e la differenza si vede negli strumenti da usare e nell’ordine in cui usarli.
Il metro di misura: I/O wait e perché da solo non bastaL’I/O wait (colonna wa in top) è la percentuale di tempo in cui la CPU è rimasta inattiva pur avendo almeno una richiesta di I/O ancora in sospeso. È un indicatore utile ma ingannevole: se il sistema ha altro lavoro da eseguire mentre il disco è lento, la CPU si tiene occupata e il valore di wa scende, anche se lo storage sottostante continua a rispondere altrettanto male. Per questo motivo l’I/O wait va sempre incrociato con metriche a livello di dispositivo, non usato come unico segnale.
Il flusso diagnostico corretto segue quattro passaggi in sequenza:
Controllare load average e colonna wa in top (premendo 1 per espandere le statistiche per singolo core)
Confermare il sospetto a livello di dispositivo con iostat -xz 1 o /proc/pressure/io
Solo a questo punto, andare a caccia dei processi responsabili con atop e iotop
Misurare in modo oggettivo con un benchmark reale (dd o fio), perché un numero concreto chiude ogni discussione
Passo 1 — Individuare i processi bloccatiPrima di aprire strumenti dedicati, un controllo rapido dei processi in stato “uninterruptible sleep” dà già un’indicazione:
ps -eo state,pid,comm | grep "^D"Se questo comando restituisce più righe, ripetutamente, su un sistema che dovrebbe essere reattivo, l’ipotesi I/O-bound si rafforza. Il passo successivo è capire quanto è grave la situazione a livello di dispositivo di blocco.
Passo 2 — iostat: la vista a livello di dispositivoiostat -xz 1I flag hanno un significato preciso:
-x: statistiche estese, incluse le latenze medie di lettura e scrittura
-z: nasconde i dispositivi inattivi, per non affollare l’output con righe a zero
1: intervallo di refresh in secondi
Le colonne da guardare con attenzione sono r_await e w_await, che esprimono in millisecondi il tempo medio di attesa per operazione di lettura e scrittura: su storage sano questi valori restano a una cifra; valori a due o tre cifre indicano un disco sotto stress severo. La colonna %util va invece presa con cautela sui dispositivi SSD/NVMe, dove può risultare fuorviante a causa del parallelismo interno dei controller moderni, che gestiscono più richieste contemporaneamente senza che questo si traduca in saturazione reale.
Un dettaglio pratico spesso ignorato: il primo report stampato da iostat va scartato, perché media tutte le statistiche dall’avvio del sistema e può “truccare” in positivo un disco che in realtà ha iniziato a comportarsi male solo poche ore prima.
Passo 3 — Pressure Stall Information: la metrica più modernaDai kernel 4.20 in poi è disponibile un meccanismo più sofisticato dell’I/O wait tradizionale: la Pressure Stall Information (PSI), esposta in /proc/pressure/io:
cat /proc/pressure/ioUn output tipico in condizioni di forte stress si presenta così:
some avg10=44.21 avg60=39.07 avg300=31.88 total=8814592211
full avg10=38.90 avg60=35.62 avg300=29.15 total=7913804412La riga some indica la percentuale di tempo in cui almeno un task era bloccato in attesa di I/O; la riga full indica la percentuale di tempo in cui tutti i task non idle erano bloccati contemporaneamente — un segnale molto più grave, perché significa che l’intero sistema è fermo in attesa dello storage. Su alcune distribuzioni PSI richiede il parametro di avvio del kernel psi=1 per essere attivo; vale la pena verificarlo prima di fare affidamento su questi dati in produzione.
Passo 4 — Trovare il colpevole con atop e iotopUna volta confermato che il collo di bottiglia è reale a livello di dispositivo, resta da capire quale processo lo sta generando.
atop mostra le statistiche di I/O per disco direttamente nella vista principale; premendo d durante l’esecuzione si passa alla vista dedicata ai processi che stanno consumando I/O. È utile anche per individuare thread kernel come flush-8:0 (il thread di writeback che scarica su disco le pagine sporche dalla cache) o jbd2/sda5-8 (il journaling di ext4), che spesso vengono scambiati per processi “misteriosi” da chi non li conosce.
iotop offre una vista più mirata:
iotop -oPa-o (--only): mostra solo i processi che stanno effettivamente generando I/O in quel momento
-P (--processes): aggrega per processo invece di elencare ogni singolo thread
-a (--accumulated): mostra il totale di I/O accumulato dall’avvio dello strumento, utile per individuare pattern intermittenti
Un requisito spesso trascurato: dal kernel 5.14 il delay accounting è disabilitato di default, e senza di esso iotop non riesce a calcolare correttamente le statistiche per processo. Va abilitato con:
sudo sysctl kernel.task_delayacct=1Per renderlo persistente ai riavvi è necessario aggiungere delayacct ai parametri di boot del kernel (tramite GRUB), oltre a impostare il sysctl in /etc/sysctl.d/.
Chiudere la discussione con un numero: dd e fioQuando la diagnosi è fatta, spesso serve convincere qualcun altro (un cliente, un team infrastrutturale, un fornitore di storage) che il problema è reale. Un test rapido e riproducibile con dd:
dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasyncIl flag conv=fdatasync è essenziale: forza la sincronizzazione dei dati su disco prima che dd riporti il tempo trascorso, altrimenti si misurerebbe solo la velocità della cache di scrittura del kernel. Un risultato come “1073741824 bytes (1.1 GB) copiati, 46.0156 s, 23.3 MB/s” su uno storage che dovrebbe erogare centinaia di MB/s parla da solo, ed è molto più difficile da contestare di un’opinione: un host può discutere con la vostra opinione, molto più difficilmente lo farà con 23,3 MB/s misurati.
Per un quadro più completo, che tenga conto anche di IOPS e latenza sotto carico concorrente (lo scenario tipico di un database o di un server #web sotto traffico reale), lo strumento di riferimento è fio, che permette di simulare pattern di accesso realistici con più job paralleli, dimensioni di blocco configurabili e miscele di letture/scritture.
Il caso reale: quando il disco lento innesca un effetto dominoUn caso concreto che vale la pena analizzare riguarda un server con un’istanza MySQL configurata con max_connections=2000, un valore decisamente eccessivo per l’hardware disponibile. Ogni connessione MySQL alloca buffer per-thread; moltiplicando la memoria per singolo thread per il numero massimo di connessioni e sommando i buffer globali, il calcolo della memoria potenzialmente necessaria superava ampiamente la RAM installata.
Finché il traffico restava basso, il problema non si manifestava. Ma con un disco già lento (a causa di I/O wait elevato) e un picco di connessioni concorrenti, le richieste si sono accumulate in coda, la pressione di memoria è salita rapidamente, e l’OOM killer del kernel è intervenuto terminando processi critici. Un problema di storage, in altre parole, si è propagato fino a diventare un incidente di memoria e disponibilità.
Buone pratiche per prevenire il problemaAlcune misure pratiche riducono sensibilmente il rischio di trovarsi in questa situazione:
Ridurre la frequenza di scrittura dei log di #Nginx/Apache in scenari ad alto traffico, dove i log di accesso possono generare un volume di I/O sorprendentemente alto
Spostare la cache in memoria (ad esempio su tmpfs) invece che su disco durante i picchi di concorrenza, per eliminare completamente la latenza di storage dal percorso critico
Dimensionare correttamente pm.max_children in #PHP-FPM: un valore troppo basso rifiuta traffico legittimo, uno troppo alto amplifica la pressione su disco e memoria nello stesso momento
Valutare l’hardware: il salto da storage a rotazione a SSD, e da SSD a NVMe, cambia le soglie di r_await/w_await di un ordine di grandezza
Introdurre un livello di #caching come Varnish davanti all’applicazione, una volta che la cache è “primed” e può assorbire la maggior parte delle richieste senza toccare il backend
ConclusioneUn load average alto con CPU libera non è un paradosso: è un sintomo preciso che indica dove guardare. Il metodo — top per una prima ipotesi, iostat e PSI per confermarla a livello di dispositivo, atop/iotop per individuare il processo responsabile, e un benchmark con dd o fio per quantificare il problema in modo indiscutibile — si applica a qualunque stack, dai database ai server web, ed evita di perdere tempo a ottimizzare la CPU quando il vero collo di bottiglia sta girando a 23 MB/s su un disco che dovrebbe farne dieci volte tanto.
Fonte originale: Linux server performance: Is disk I/O slowing your application? – LinuxBlog.io
