Server overload: diagnosi e mitigazione

Un server in overload e un'host che non riesce a servire le richieste in tempi accettabili a causa della saturazione di una o più risorse. Diagnosticare la causa esatta - CPU, memoria, disco, rete o applicazione - e il primo passo per riportare il sistema in salute senza interventi improvvisati.

Identificare la risorsa critica

L'overload puo manifestarsi in modi diversi: lentezza, timeout, errori 502/503, processi killati dall'OOM killer. Inizia con una panoramica veloce: top, htop, vmstat 2 10. Le quattro aree da esaminare sono CPU, RAM, disco, rete. La quinta dimensione e applicativa: locks, code, query lente che amplificano il carico.

CPU saturata

Se il load average supera stabilmente il numero di core e %us e oltre il 90 percento, hai overload CPU. Identifica i processi col ps aux --sort=-%cpu | head. Cause tipiche: bot/scraper aggressivi, processi runaway, regex catastrofiche, mining malware. Mitigazione: rate limiting a livello applicazione o Nginx, scaling orizzontale, profiling del codice.

RAM esaurita

Memoria fisica satura porta a swap intenso e OOM killer. Verifica con free -h e dmesg -T | grep -i oom. Identifica i top consumer con ps aux --sort=-%mem. Mitigazione: aumentare RAM, ridurre innodb_buffer_pool, limitare worker PHP-FPM, configurare cgroup limits.

Disco lento o pieno

I/O wait elevato in top indica saturazione storage. iostat -x 2 mostra util% e await per disco. iotop identifica i processi I/O-heavy. Cause tipiche: backup in orario sbagliato, log rotation pesante, database non ottimizzato. Mitigazione: tuning del database, riallocazione dei carichi I/O, passaggio a SSD NVMe.

Rete satura

Verifica con nload, iftop, vnstat. Se la banda e satura puoi vedere richieste in coda lato applicazione. Possibili cause: DDoS, scraping massivo, backup esterni in orario produttivo. Mitigazione: CDN, WAF, traffic shaping, blocco IP malevoli, separazione del traffico di backup.

Procedura passo-passo

1. Cattura una snapshot generale con top -bn1 | head -50.
2. Identifica la risorsa satura tramite vmstat, iostat, sar.
3. Localizza i processi colpevoli con ps, htop, iotop.
4. Verifica i log applicativi: errori, lock, query lente.
5. Applica una mitigazione immediata (kill processo runaway, abilitare cache, rate limit).
6. Pianifica la soluzione strutturale: scaling, ottimizzazione codice, hardware aggiuntivo.
7. Aggiungi alerting proattivo per non subire più lo stesso pattern.

Errori comuni e come risolverli

• Riavviare senza diagnosticare: il problema torna, perdi le evidenze.
• Aggiungere risorse alla cieca: a volte il bottleneck e una query mancante di indice.
• Ignorare i log: spesso la causa e li, basta cercarla.
• Affidarsi solo al monitoring real-time: senza storico non capisci se e un picco o una tendenza.

Domande frequenti

D: Esiste un tool unico per la diagnosi?
R: Strumenti come atop, sysstat (sar), netdata coprono molti aspetti contemporaneamente.

D: Come prevenire overload futuri?
R: Capacity planning trimestrale, alert su soglie, autoscaling per workload variabili.

D: Quando passare a un cluster?
R: Quando il singolo host non scala in verticale o quando l SLA richiede ridondanza.

Approfondimento tecnico: PSI e cgroup pressure

Il Pressure Stall Information (PSI) e un meccanismo del kernel Linux (4.20+) che misura quanto i processi attendono per risorse (CPU, memoria, I/O). I file /proc/pressure/cpu, /proc/pressure/memory e /proc/pressure/io espongono percentuali some (almeno un task in stallo) e full (tutti i task in stallo). Sono metriche più precise del classico load average per diagnosticare overload, perché separano CPU, RAM e disco.

Con i cgroup v2 ogni gruppo ha le sue metriche PSI in /sys/fs/cgroup/.../memory.pressure. Strumenti come resctl-bench di Facebook usano PSI per identificare quale workload causa contesa. In monitoring moderno (cAdvisor, Netdata) le PSI sono ormai standard.

Scenari d'uso reali

Un e-commerce sotto Black Friday diagnostica overload via PSI: memory.pressure full al 30 percento indica swap thrashing. Soluzione: aggiungere RAM, ridurre buffer DB.

Un cluster Kubernetes con pod oomkilled scopre via cgroup pressure quale namespace consuma più memoria.

Un server applicativo Java con io.pressure alto rivela log troppo verbosi che saturano l SSD.

Checklist operativa anti-overload

• Monitoring proattivo con soglie ben tarate.
• Capacity planning trimestrale.
• Procedure documentate per ogni tipo di saturazione (CPU, RAM, I/O, rete).
• Rate limiting applicativo per traffico anomalo.
• CDN davanti per assorbire picchi su asset statici.
• Auto-scaling configurato per workload variabili.
• Post-mortem di ogni incidente per imparare e prevenire.

Risorse e riferimenti

SRE Book di Google (sre.google/books) per pattern di gestione overload e graceful degradation. Brendan Gregg performance methodology per troubleshooting sistematico. Strumenti: sysstat, bcc-tools, perf. Pattern come circuit breaker e backpressure sono fondamentali in architetture distribuite.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su server overload 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.