Load average server: cosa significa davvero

Il load average e una delle metriche più citate e fraintese nei server Linux. Spesso interpretato come "percentuale di CPU usata", in realta misura qualcosa di diverso e molto più informativo. Capirne il vero significato aiuta a diagnosticare con precisione i colli di bottiglia.

Cosa misura davvero

Il load average rappresenta il numero medio di processi in stato runnable o in attesa di I/O ininterrompibile, calcolato su finestre mobili di 1, 5 e 15 minuti. Non e una percentuale: e una grandezza assoluta. Su un sistema con 4 core un load di 4.0 significa che mediamente ogni core ha un processo in coda; un load di 8.0 indica saturazione e contesa.

Relazione con i core CPU

Per interpretare correttamente il load, dividi il valore per il numero di core: nproc oppure grep -c processor /proc/cpuinfo. Un load di 8.0 su 16 core e un carico medio (50 percento) sostenibile; lo stesso valore su 2 core e un'overload grave. La finestra di 1 minuto rivela picchi recenti, quella di 15 minuti l'andamento medio.

I/O wait nascosto

Una particolarita del load Linux: include anche i processi in uninterruptible sleep (stato D), tipicamente in attesa di disco lento o NFS bloccato. Per questo motivo un load alto puo NON corrispondere a CPU al 100 percento. Usa top o iostat per verificare la quota iowait: se e alta, il problema e nello storage non nella CPU.

Procedura passo-passo per diagnosticare un load alto

1. Leggi load average con uptime o cat /proc/loadavg.
2. Conta i core con nproc e calcola il rapporto.
3. Lancia top o htop per identificare i processi in cima alla lista.
4. Controlla %us, %sy, %wa, %id in top: se wa e alto, indaga lo storage.
5. Usa iostat -x 2 per metriche per disco (await, util%).
6. Verifica swap usage con free -h: paginazione attiva amplifica i load.
7. Cerca processi zombie o D-state con ps -eo pid,state,cmd | grep " D".
8. Se sospetti software, prendi un sample con perf top o strace -p PID.

Errori comuni e come risolverli

• Allarmarsi per load > 1 senza contesto: senza il numero di core il valore e privo di significato.
• Confondere load con CPU%: sono metriche diverse, vanno lette insieme.
• Ignorare iowait: spesso il "load alto" e in realta storage lento.
• Reboot affrettato: prima diagnostica, altrimenti il problema riemerge.

Domande frequenti

D: Qual e un load "buono"?
R: Per produzione, mantenere il rapporto load/core sotto 0.7 lascia margine per i picchi.

D: Su VM virtualizzate il load e affidabile?
R: Si ma considera anche steal time: se l'hypervisor satura, i vCPU attendono e il load sembra alto senza colpa dell'applicazione.

D: Esiste un'equivalente per Windows?
R: Windows non ha load average, usa Processor Queue Length e Processor Time.

Approfondimento tecnico: il calcolo esatto del load

Il load average e calcolato dal kernel come media esponenziale mobile (EMA) del numero di task in stato R (runnable) o D (uninterruptible sleep). I tre valori 1/5/15 minuti hanno fattori di decay diversi. Il sample avviene ogni 5 secondi, da qui la cadenza. Il valore non e percentuale e non ha tetto: puo raggiungere centinaia se il sistema e gravemente in coda.

Una particolarita storica: i task in D-state contano. Questo significa che un disco lento o un NFS bloccato gonfia il load anche se la CPU e idle. Per separare il fenomeno usa /proc/pressure/cpu e /proc/pressure/io (Pressure Stall Information, dal kernel 4.20): metriche più specifiche introdotte da Facebook.

Scenari d'uso reali

Un web server con load 12 su 16 core e situazione normale: 75 percento di utilizzo, margine per picchi.

Un server NFS client con load 50 ma CPU al 5 percento indica problemi di rete o NFS server lento: indagare con nfsstat.

Un database OLTP con load crescente nel tempo ma stesso traffico spesso ha indici mancanti o tabelle che richiedono ANALYZE.

Checklist operativa per la lettura del load

• Sempre rapportare il load al numero di core (nproc).
• Distingui CPU bound, I/O bound, memory bound.
• Verifica steal time su VM virtualizzate.
• Usa Pressure Stall Information per metriche moderne.
• Alert con soglia load/core > 0.8 per 5 minuti.
• Correla con metriche applicative (response time, error rate).
• Documenta i baseline per ogni server.

Risorse e riferimenti

Articoli di Brendan Gregg (brendangregg.com) sul significato di load average. Documentazione kernel su PSI: kernel.org/doc/html/latest/accounting/psi.html. Strumenti: atop per storico, perf per profiling, BCC tools per eBPF tracing avanzato.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su load average server richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.