Come verificare in dettaglio la Load Average dal terminale
La Load Average è uno degli indicatori più utili per capire se un sistema Linux sta lavorando in modo regolare oppure è sotto pressione. Spesso viene letta in fretta con un semplice uptime, ma per interpretarla davvero bene serve guardare cosa misura, come varia nel tempo e soprattutto quali risorse stanno creando attesa: CPU, disco, I/O, processi bloccati o code di esecuzione.
Questa guida ti mostra come controllarla in modo dettagliato dal terminale, con comandi pratici e criteri di lettura affidabili. L’obiettivo non è solo vedere un numero, ma capire se quel numero è normale per il tuo server oppure indica un collo di bottiglia.
Cos’è davvero la Load Average
Su Linux la Load Average rappresenta il numero medio di processi che, in un certo intervallo di tempo, sono:
- in esecuzione sulla CPU;
- pronti a eseguire ma in attesa di CPU;
- in stato di attesa non interrompibile, di solito per I/O su disco o su storage di rete.
Di solito viene mostrata con tre valori:
- 1 minuto: carico molto recente;
- 5 minuti: media breve;
- 15 minuti: media più stabile.
Esempio tipico:
load average: 0.42, 0.58, 0.61Questi numeri non sono percentuali. Non significano “42% di utilizzo”. Indicano una media di processi in coda o in esecuzione.
Un valore di Load Average va sempre letto insieme al numero di CPU core e allo stato dei processi. Un valore “alto” su un server a 32 core può essere normale, mentre lo stesso valore su un VPS a 1 core può indicare saturazione.
Il comando più rapido: uptime
Il modo più semplice per vedere la Load Average è:
uptimeOutput di esempio:
10:25:41 up 12 days, 3:14, 2 users, load average: 1.15, 0.98, 0.76Qui puoi leggere:
- ora corrente;
- da quanto tempo il sistema è acceso;
- numero di utenti collegati;
- Load Average a 1, 5 e 15 minuti.
Quando usarlo: per un controllo immediato. Limite: non ti dice quali processi stanno causando il carico.
Controllare la Load Average in tempo reale con top
Il comando top è uno dei più utili perché mostra sia il carico globale sia i processi che consumano risorse.
topIn alto troverai una riga simile a questa:
top - 10:27:12 up 12 days, 3:16, 2 users, load average: 2.35, 1.80, 1.20Subito sotto, osserva:
- %us: CPU in user space;
- %sy: CPU in kernel space;
- %id: CPU idle;
- %wa: attesa I/O;
- %st: steal time, importante su VPS e ambienti virtualizzati.
Se la Load Average è alta ma %id resta elevato, il problema potrebbe non essere la CPU. Se invece %wa è alto, spesso il collo di bottiglia è il disco o lo storage.
In top puoi anche ordinare i processi per consumo con P per CPU e M per memoria. Questo aiuta a capire se un processo specifico sta contribuendo al carico.
Usare htop per una lettura più chiara
Se disponibile, htop è spesso più leggibile di top.
htopVantaggi pratici:
- grafici colorati delle CPU;
- memoria e swap più visibili;
- ordinamento interattivo dei processi;
- filtri e ricerca più comodi.
In alto puoi vedere il numero di core e il carico per CPU. Se una o più CPU sono costantemente al 100% e la Load Average cresce, il sistema sta saturando la capacità di calcolo o sta aspettando I/O.
Se htop non è installato, puoi aggiungerlo nei sistemi Debian/Ubuntu con:
sudo apt install htope nei sistemi Alma/Rocky/CentOS con:
sudo dnf install htopVerifica successiva: riapri htop e controlla se i processi più pesanti corrispondono ai picchi di load.
Leggere la Load Average da /proc/loadavg
Linux espone il dato anche in un file virtuale del kernel:
cat /proc/loadavgEsempio di output:
0.32 0.41 0.38 1/245 12345Significato dei campi:
- 0.32: media a 1 minuto;
- 0.41: media a 5 minuti;
- 0.38: media a 15 minuti;
- 1/245: processi attivi / processi totali;
- 12345: PID dell’ultimo processo creato.
Questo comando è utile negli script o quando vuoi estrarre il dato in modo semplice e veloce.
Verificare il numero di CPU core
Per interpretare correttamente la Load Average devi sempre confrontarla con il numero di core disponibili.
nprocOutput atteso: un numero intero, per esempio 2, 4, 8, 16.
Puoi anche usare:
lscpue cercare:
- CPU(s): numero totale di CPU logiche;
- Core(s) per socket;
- Thread(s) per core.
Regola pratica: una Load Average pari al numero di core non è automaticamente un problema. Su un server a 4 core, una load di 4 può essere perfettamente normale se il sistema è occupato ma reattivo. Su un server a 1 core, una load di 4 è invece un chiaro segnale di coda.
Confrontare la Load Average con lo stato della CPU
Per capire se il carico è CPU-bound o I/O-bound, osserva questi comandi insieme:
vmstat 1Le colonne più utili sono:
- r: processi in run queue;
- b: processi bloccati;
- us: CPU utente;
- sy: CPU sistema;
- id: CPU inattiva;
- wa: attesa I/O.
Interpretazione rapida:
- r alto e id basso: CPU satura;
- b alto e wa alto: attesa I/O;
- r alto ma us/sy non alti: possibile contesa, schedulazione o problemi di virtualizzazione.
Se vuoi vedere il comportamento nel tempo, lascia vmstat 1 attivo per alcuni secondi e osserva la stabilità dei valori.
Trovare i processi che generano il carico
La Load Average è un sintomo, non la causa. Per trovare il colpevole devi cercare i processi attivi o bloccati.
Con top o htop puoi ordinare per CPU. In alternativa, usa:
ps -eo pid,ppid,user,stat,pcpu,pmem,comm --sort=-pcpu | head -20Questo mostra i primi 20 processi per consumo CPU. Se sospetti un problema di I/O, prova anche:
ps -eo pid,ppid,user,stat,pcpu,pmem,comm --sort=-pmem | head -20Oppure, per vedere processi bloccati:
ps -eo pid,stat,comm | awk '$2 ~ /D/ {print}'Lo stato D indica spesso attesa non interrompibile, tipica di problemi disco, storage o filesystem.
Capire se il problema è disco o storage
Molti casi di Load Average alta non dipendono dalla CPU, ma dall’I/O. Per verificare usa:
iostat -xz 1Se il comando non è presente, su Debian/Ubuntu arriva con sysstat:
sudo apt install sysstate su Alma/Rocky/CentOS con:
sudo dnf install sysstatIndicatori da osservare:
- %util vicino al 100%: disco molto impegnato;
- await alto: tempi di attesa elevati;
- svctm non sempre affidabile su kernel moderni, meglio guardare await e %util.
Se iostat mostra disco saturo e top evidenzia processi in stato D, la Load Average alta è probabilmente causata da I/O lento.
Osservare la Load Average nel tempo
Per capire se il problema è occasionale o persistente, puoi monitorare il dato ogni secondo:
watch -n 1 cat /proc/loadavgOppure, se vuoi un output più leggibile:
watch -n 1 uptimeQuesto è utile per vedere se il carico sale in corrispondenza di backup, cron, import, scansioni antivirus, picchi web o job applicativi.
Se vuoi registrare l’andamento nel tempo, puoi fare un loop semplice:
while true; do date '+%F %T'; cat /proc/loadavg; sleep 5; doneInterrompi con Ctrl+C.
Interpretazione pratica delle soglie
Non esiste una soglia universale valida per tutti i server. Però puoi usare queste regole pratiche:
- Load < numero di core: spesso accettabile, se il server è reattivo;
- Load simile ai core: possibile saturazione, da controllare con CPU e I/O;
- Load molto sopra i core: forte coda di processi, indagine necessaria;
- Load alta ma CPU bassa: spesso I/O, swap o processi bloccati;
- Load alta e swap attivo: possibile pressione memoria.
Esempio: su un server a 2 core, una Load Average di 0.8 0.9 1.0 può essere sana. Su un server a 2 core, una Load Average di 8.0 7.5 6.9 è quasi certamente anomala.
Controllare anche la memoria e lo swap
La Load Average può salire quando il sistema va in pressione di memoria e inizia a usare swap. Per verificare:
free -hOsserva:
- available: memoria realmente disponibile;
- swap used: se cresce molto, il sistema potrebbe rallentare;
- buffers/cache: non confondere cache con memoria persa.
Se la memoria disponibile è bassa e lo swap è attivo in modo costante, il sistema può mostrare Load Average elevata anche senza CPU pienamente saturata.
Controllare i log quando la Load Average sale
Se la causa non è evidente, guarda i log di sistema e del kernel. Su sistemi con systemd:
journalctl -p warning -bPer il kernel:
dmesg -T | tail -100Cerca segnali come:
- errori disco;
- filesystem in sola lettura;
- OOM killer;
- timeout di rete o storage;
- driver o kernel panic parziali.
Se trovi messaggi di I/O error, la Load Average alta è spesso un effetto collaterale di un problema più profondo sul sottosistema storage.
Uso avanzato: processi in stato D e attese kernel
Una delle cause più subdole di Load Average alta è la presenza di molti processi in stato D. Questi processi non stanno usando CPU, ma stanno aspettando una risorsa non interrompibile.
Puoi elencarli con:
ps -eo pid,ppid,user,stat,wchan:25,comm | awk '$4 ~ /D/ {print}'La colonna wchan può aiutarti a capire dove stanno aspettando. Non sempre è leggibile in modo immediato, ma è utile per indagini più avanzate.
Se vuoi una vista più ampia dei blocchi kernel, puoi usare anche strumenti come pidstat, iotop o strace, ma solo dopo aver escluso le cause più semplici.
Strumenti utili per un controllo rapido
Una mini checklist di comandi molto utili:
uptimeper la Load Average immediata;topper vedere CPU, I/O e processi;htopper una lettura più chiara;nprocolscpuper confrontare con i core;vmstat 1per coda e attesa;iostat -xz 1per il disco;free -hper memoria e swap;journalctl -p warning -bedmesg -Tper i log.
Esempio pratico di diagnosi
Immagina questo scenario:
load average: 6.40, 5.90, 4.80Il server ha 4 core. Con top vedi %wa al 35% e diversi processi in stato D. Con iostat -xz 1 il disco mostra %util vicino al 100% e await alto. In questo caso la Load Average non indica CPU al limite, ma un collo di bottiglia I/O.
In un altro scenario, la Load Average è simile ma la CPU è al 95% di utilizzo, %wa è basso e ps mostra un processo PHP, Java o database che consuma molto. Qui il problema è CPU-bound.
Questo confronto è fondamentale: la Load Average da sola non basta per fare una diagnosi corretta.
Quando preoccuparsi davvero
Dovresti approfondire subito se noti una o più di queste condizioni:
- Load Average che cresce stabilmente senza rientrare;
- server lento anche con poche richieste;
- processi in stato
Dnumerosi; - swap che aumenta in modo persistente;
- disco con
%utilmolto alto; - errori nei log kernel o filesystem;
- tempi di risposta web in aumento, timeout o code applicative.
In un contesto hosting o produzione, la Load Average alta va letta insieme a TTFB, slow query, code PHP-FPM, saturazione del database e stato dello storage.
Procedura rapida consigliata
Se vuoi fare una verifica completa in pochi minuti, segui questo ordine:
- esegui
uptimee annota i tre valori di load; - controlla i core con
nproc; - apri
topohtope guarda%wa,%ide i processi più pesanti; - usa
vmstat 1per capire se ci sono processi in coda o bloccati; - se sospetti il disco, lancia
iostat -xz 1; - verifica memoria e swap con
free -h; - controlla i log con
journalctl -p warning -bedmesg -T.
Con questa sequenza, nella maggior parte dei casi riesci a capire se il problema è CPU, I/O, memoria o un processo specifico.
Conclusione operativa
La Load Average è un indicatore potente, ma va sempre interpretata nel contesto giusto. Il numero da solo non basta: devi confrontarlo con i core, guardare CPU e I/O, osservare i processi e leggere i log. In pratica, non chiederti solo “quanto è alta la load?”, ma “perché è alta?”.
Se impari a usare insieme uptime, top, vmstat, iostat e free -h, avrai una diagnosi molto più affidabile e potrai distinguere un picco normale da un vero problema di performance.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.