Como lidar com eventos do OOM Killer - Quando processos são encerrados por esgotamento de memória

2026-05-31 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário

O que é o OOM killer?

O OOM killer (Out-Of-Memory killer) é um mecanismo do kernel Linux que encerra processos à força quando tanto a memória física quanto o swap estão esgotados. Seu objetivo é prevenir uma falha completa do sistema. Quando um processo desaparece sem explicação — sem log de crash no nível da aplicação, exit code SIGKILL no systemctl status — o OOM killer é a primeira coisa a verificar.

Como confirmar um evento do OOM killer nos logs

Quando o OOM killer atua, o kernel sempre escreve um registro no buffer de anel do kernel e no log do sistema. Comece por aqui.

Verificar com dmesg

sudo dmesg | grep -i "out of memory"
sudo dmesg | grep -i "oom"

[1234567.890] Out of memory: Killed process 12345 (nginx) total-vm:512000kB, anon-rss:256000kB, file-rss:8000kB, shmem-rss:0kB, UID:0 pgtables:512kB oom_score_adj:0

Buscar no log do kernel com journalctl

sudo journalctl -k --since "2 hours ago" | grep -i oom
sudo journalctl -k -g "Out of memory"

A flag -k filtra apenas mensagens do kernel. Use --since para restringir a janela de tempo.

Verificar syslog / kern.log

sudo grep -i "out of memory" /var/log/syslog
sudo grep -i "oom_killer" /var/log/kern.log

Identificando qual processo foi encerrado

O log registra informações detalhadas sobre o processo encerrado.

sudo dmesg | grep "Killed process"

[1234567.890] Killed process 12345 (nginx) total-vm:512000kB, anon-rss:256000kB

Lendo a saída:

Para ver o estado da memória no momento do evento, imprima o contexto ao redor da mensagem OOM:

sudo dmesg | grep -A 30 "Out of memory" | head -50

Como funcionam os scores OOM

O kernel atribui a cada processo um oom_score (0-1000). Score mais alto significa maior prioridade de encerramento. O score é baseado principalmente no uso de memória relativo ao total de RAM física.

Verificar o score atual

cat /proc/<PID>/oom_score

Listar todos os processos ordenados por score OOM (maior primeiro):

awk '{print $1}' /proc/*/status 2>/dev/null | \
  xargs -I{} sh -c 'echo "$(cat /proc/{}/oom_score 2>/dev/null) {} $(cat /proc/{}/comm 2>/dev/null)"' | \
  sort -rn | head -20

Ajustando o score com oom_score_adj

Escreva um valor de -1000 a 1000 em /proc/<PID>/oom_score_adj para influenciar o score.

# Tornar nginx muito mais dificil de ser encerrado pelo OOM (temporario)
echo -500 | sudo tee /proc/$(pgrep nginx)/oom_score_adj

Resposta imediata — reiniciar e recuperar memória

Após o OOM killer atuar, a memória disponível deve ser restaurada. Porém, a causa raiz provavelmente persiste e o evento vai se repetir.

Reiniciar o serviço encerrado

sudo systemctl restart <service-name>

Liberar page cache manualmente

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches

Encontrar os maiores consumidores de memória

ps aux --sort=-%mem | head -20
free -h

Tornando oom_score_adj persistente

O valor de oom_score_adj é redefinido quando um processo reinicia. Para persisti-lo, adicione a configuração ao arquivo de unidade do systemd.

sudo systemctl edit <service-name>

Adicione o seguinte:

[Service]
OOMScoreAdjust=-500

Aplique a alteração:

sudo systemctl daemon-reload
sudo systemctl restart <service-name>

Verifique:

cat /proc/$(pgrep <service>)/oom_score_adj

Adicionando swap para reduzir pressão de memória

Swap ausente ou insuficiente torna eventos do OOM killer mais prováveis. Adicionar um arquivo de swap fornece um buffer para picos repentinos de memória.

Criar um arquivo de swap

# Criar um arquivo de swap de 2 GB
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Confirme que está ativo:

free -h
swapon --show

              total        used        free      shared  buff/cache   available
Mem:           3.8G        3.1G        100M         50M        600M        600M
Swap:          2.0G          0B        2.0G

Persistir entre reboots

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Causa raiz — auditar configuração de memória

Eventos recorrentes do OOM killer significam que o sistema está genuinamente ficando sem memória. Ajuste de score e swap são mitigações, não correções.

Causas raiz comuns

1. Vazamento de memória — RSS cresce ao longo do tempo sem liberação
2. Configuração de memória superdimensionada — JVM -Xmx, innodb_buffer_pool_size ou similar excede a RAM física
3. Muitos workers simultâneos — Apache MaxRequestWorkers, PHP-FPM pm.max_children, etc.

Monitorar crescimento de RSS ao longo do tempo

# Amostrar memoria a cada 5 segundos
watch -n 5 "ps -p <PID> -o pid,rss,vsz,comm"

Limitar memória do serviço com cgroup (via systemd)

Definir um teto explícito de memória por serviço isola falhas e previne que um processo descontrolado derrube o sistema.

sudo systemctl edit <service-name>

[Service]
MemoryMax=512M
MemorySwapMax=0

Quando o limite é atingido, apenas aquele serviço é encerrado — os outros processos não são afetados.