Server "out of memory": diagnosi e fix

Quando un server Linux esaurisce la memoria, entra in azione l OOM killer: il kernel termina processi per liberare RAM e mantenere il sistema in vita. L'evento e raramente "innocente": indica saturazione cronica, memory leak o dimensionamento errato. Vediamo come diagnosticare e risolvere.

Capire l'evento

Il primo comando da eseguire e dmesg -T | grep -i -E "killed process|out of memory". Vedrai righe del tipo "Out of memory: Killed process 12345 (mysql) score 957". Lo score indica l'euristica di scelta del kernel: più alto, più candidato. Annota il timestamp e correla con i grafici di monitoring (Netdata, Prometheus) per capire l'andamento RAM.

Strumenti diagnostici

• free -h: panoramica RAM e swap.
• top o htop: processi ordinati per memoria.
• ps aux --sort=-%mem | head: top consumer.
• smem -tk: memoria con USS/PSS (più accurato di RSS).
• cat /proc/meminfo: dettaglio dei buffer e cache.
• vmstat 1: paginazione in tempo reale.

Cause tipiche

Le cause più frequenti di OOM sono: buffer pool MySQL/PostgreSQL sovradimensionato, worker PHP-FPM senza limiti, memory leak applicativo (Node.js, Python), cron job che caricano dati massivi, backup in parallelo, Java JVM senza Xmx, container Docker senza limits.

Procedura passo-passo

1. Identifica il processo killato e il timestamp.
2. Esamina i log applicativi prima dell'evento.
3. Verifica trend RAM nel monitoring: lento aumento = leak, picco = job specifico.
4. Verifica configurazione dei servizi (memory limits, pool size, max_clients).
5. Aggiungi swap proporzionato (1-2x RAM, max 8-16 GB) per assorbire picchi.
6. Imposta cgroup limits via systemd: MemoryMax=4G nel unit file.
7. Tuna PHP-FPM pm.max_children e pm.max_requests per evitare crescita perpetua.
8. Riduci buffer DB se sovradimensionati.
9. Aggiungi alerting: alert quando RAM > 85 percento per 10 minuti.
10. Pianifica upgrade RAM se il workload e cresciuto strutturalmente.

Swap: utile o no?

Lo swap NON salva un server da OOM cronico: rallenta tutto e nasconde il problema. Però un piccolo swap (1 GB) e utile per assorbire picchi transitori senza scatenare OOM killer. Imposta vm.swappiness=10 per ridurre l'uso preventivo. Su VM cloud spesso swap e assente: aggiungilo con un file via fallocate.

Errori comuni e come risolverli

• Aumentare la RAM senza analizzare: se c e leak, si rimanda solo il problema.
• Disabilitare OOM killer: senza, il sistema si blocca; non e una soluzione.
• Swap troppo grande: rallenta enormemente il server in caso di paginazione.
• Container senza limits: un container puo affamare l'host.

Domande frequenti

D: Come escludo un processo critico dall'OOM killer?
R: Scrivi -1000 in /proc/PID/oom_score_adj. Solo per casi davvero critici.

D: Posso prevenire OOM al 100 percento?
R: No: monitoring, limits e dimensionamento adeguato lo rendono raro.

D: La cache del kernel conta come RAM usata?
R: free -h mostra "available": e il valore davvero utilizzabile.

Approfondimento tecnico: memory cgroup e ZRAM

I memory cgroup permettono di limitare la memoria per gruppo di processi. In systemd: MemoryMax=2G nel unit file imposta un tetto rigido; il superamento porta a OOM killer interno al cgroup senza coinvolgere l'host. Utile per isolare servizi: un PHP-FPM impazzito non puo affamare MySQL.

ZRAM e una alternativa allo swap su disco: comprime la RAM stessa in un blocco device. La compressione (LZ4, ZSTD) recupera 2-3x lo spazio originale. Su VPS senza disco swap, ZRAM permette di assorbire picchi senza I/O. Configurabile con zram-tools o systemd unit. La swappiness alta (60-100) favorisce ZRAM rispetto a swap su disco.

Scenari d'uso reali

Un server WordPress multi-sito con 50 vhost configura cgroup per PHP-FPM pool: ogni pool max 512 MB, evitando che un sito affami gli altri.

Un VPS economico con 1 GB RAM usa ZRAM 512 MB compressed: regge picchi senza swap a disco, perdita prestazioni minima.

Un container Kubernetes con request 256Mi limit 512Mi viene oomkilled rispettando boundary del pod, non dell'host.

Checklist operativa anti-OOM

• Memory cgroup limits per servizi tramite systemd.
• Buffer DB dimensionati al 60-70 percento della RAM totale.
• Worker PHP-FPM e altri pool con limit chiari.
• Swap dimensionato per assorbire picchi (1-2x RAM, max 8 GB).
• Alert RAM > 85 percento per 10 minuti.
• OOM event logging e analisi post-incidente.
• Identificazione e fix di memory leak applicativi.

Risorse e riferimenti

Kernel docs su OOM killer e oom_score_adj. earlyoom per anticipare OOM con più controllo. nohang e alternativa avanzata. ZRAM: kernel.org/doc/html/latest/admin-guide/blockdev/zram.html. Memory profiling: massif, heaptrack.

Considerazioni economiche e organizzative

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