Linux: out of memory, killed process (OOM killer)

Come appare il messaggio

Out of memory: Killed process 2314 (php-fpm8.3) total-vm:812344kB, anon-rss:402112kB, file-rss:0kB, shmem-rss:20480kB, UID:33 pgtables:1240kB oom_score_adj:0

Cause frequenti

• Troppi worker PHP-FPM o buffer del database per la RAM disponibile.
• Memory leak in un'applicazione che cresce nel corso delle ore.
• Swap assente o troppo piccolo, i picchi di carico non vengono assorbiti.
• Limite della cgroup (MemoryMax, Docker --memory) raggiunto: allora “Memory cgroup out of memory”.
• Lavori occasionali come backup, import o elaborazione immagini che per poco usano molta memoria.

Verifica

1. Trova gli eventi OOM nel log del kernel
   journalctl -k --since '24 hours ago' | grep -iE 'out of memory|oom-kill|Killed process'Copia
2. Mostra memoria libera e swap
   free -h; swapon --showCopia
3. Mostra i processi che usano più memoria
   ps -eo pid,user,rss,comm --sort=-rss | head -n 10Copia
4. Mostra i limiti di memoria del servizio coinvolto
   systemctl show php8.3-fpm.service -p MemoryMax -p MemoryCurrent -p OOMPolicyCopia

Soluzione

• Adegua pm.max_children alla RAM: memoria disponibile diviso dimensione media di un worker.
• Limita i buffer del database, ad es. innodb_buffer_pool_size in base al resto del sistema.
• Aggiungi un po' di swap, così i picchi brevi non portano subito a un kill.
• Proteggi i servizi critici con OOMScoreAdjust=-500 nella unit e limita quelli non critici con MemoryMax.
• Monitora l'uso della memoria nel tempo per scoprire presto i leak.

Domande frequenti

Perché è stato ucciso il database se la memoria la usava PHP?

L'OOM killer sceglie in base a dimensione e oom_score_adj, non al colpevole. Servizi grandi come MariaDB vengono quindi colpiti spesso per primi.

Serve disattivare l'overcommit?

Raramente. Con vm.overcommit_memory=2 le applicazioni falliscono già all'allocazione. Meglio limiti per servizio e consumo adeguato alla RAM.