O que é o OOM Killer do Linux e por que ele fecha processos?

Publicado em 2026-10-26 por frfrand

Como o Linux reage quando falta memória, o que faz o OOM Killer e como diagnosticar um aplicativo que desaparece.

O OOM Killer é um mecanismo do kernel Linux que pode encerrar processos quando o sistema não consegue atender determinadas necessidades de memória. OOM significa out of memory. Não é que o Linux feche programas sem motivo: ele tenta recuperar capacidade em uma situação crítica.

Uma forma simples de entender

Imagine um restaurante sem espaço para atender os pedidos que chegam. Se ninguém liberar uma mesa, o gerente precisa tomar uma decisão desconfortável para evitar que tudo trave. Em um servidor, esgotar a memória pode deixar processos essenciais sem resposta.

Como funciona na prática?

O Linux administra memória física, caches e mecanismos como swap. Quando a recuperação de memória não é suficiente, ele pode ativar ações OOM. Em ambientes com cgroups, também existem limites de memória por grupo ou contêiner: um processo pode sofrer um OOM local mesmo que o host ainda tenha memória disponível.

O que não resolve e seus limites

Nem todos os processos encerrados com código 137 foram necessariamente vítimas do OOM Killer: esse código geralmente está relacionado ao SIGKILL e há outras causas. Também não basta observar um pico de RAM. É necessário revisar mensagens do kernel, limites de contêiner, uso de swap e alterações recentes. Aumentar a memória pode dar folga, mas não corrige um vazamento de memória.

Como aplicar e verificar sem surpresas

Diante de um aplicativo que desaparece, procure registros do kernel e do sistema em torno do horário do incidente. Analise o consumo por processo e seus limites; revise o tamanho de workers, concorrência e consultas que carregam dados enormes. Depois, teste a correção sob uma carga reproduzível, sem forçar reinícios automáticos intermináveis.

Como aparece no ArduMaker?

Em um VPS da ArduMaker, os limites de memória e a carga de serviços como PostgreSQL, Redis ou workers condicionam a estabilidade. Monitorar memória e logs ajuda a distinguir um processo terminado por OOM de uma falha de implantação.

O caso de um build que falha com o código 137

Um frontend pode compilar perfeitamente em um notebook e falhar ao construir dentro de um VPS pequeno. As ferramentas de compilação podem consumir muita memória durante breves períodos. Se o ambiente terminar o processo com SIGKILL, procure primeiro sinais de OOM e verifique limites reais; não culpe automaticamente o gerenciador de pacotes nem o framework.

Mais swap é suficiente?

Swap pode oferecer margem em algumas cargas, mas é mais lenta que RAM e não transforma uma máquina pequena em uma grande. Você pode reduzir a concorrência de builds, separar processos ou construir artefatos em outro ambiente antes de implantar. A solução correta depende de medir o que consome memória e quando.

Para lembrar

O OOM Killer é um mecanismo do kernel Linux que pode encerrar processos quando o sistema não consegue atender a determinadas necessidades de memória. Entender quando ele é aplicado, como falha e quais dados revisar é mais útil do que memorizar comandos soltos.

Para ampliar: Linux kernel documentation: OOM.