Interpretar a pressão de memória no Linux: free, swap, o OOM killer e OOMScoreAdjust

O que é

O free mostra a memória total, usada, livre (free), compartilhada (shared), buff/cache e disponível (available), além de uma linha para swap. Só a coluna free subestima a folga real, porque o Linux usa a memória ociosa como cache de disco; a coluna available estima quanta memória pode de fato ser entregue a um novo processo sem recorrer a swap, já considerando o cache recuperável. Quando a memória disponível e o swap se esgotam, o OOM killer (out-of-memory) do kernel escolhe um processo para encerrar e assim manter o sistema em funcionamento, e registra a ação no log do kernel, visível com dmesg ou journalctl -k.

Duas configurações de unidade do systemd influenciam esse comportamento por serviço: OOMScoreAdjust=, um valor de -1000 a 1000 gravado em /proc/[pid]/oom_score_adj, que inclina a heurística de OOM do kernel a favor ou contra o encerramento do processo (quanto mais negativo, menor a chance de ser escolhido); e MemoryMax=, um limite rígido aplicado pelo controlador de cgroup, que faz o processo ser encerrado por exceder o próprio orçamento antes que o OOM killer do sistema tenha de escolher entre serviços não relacionados.

Por que importa

Um serviço que morre sem erro na camada da aplicação e sem log de falha é um sintoma comum de OOM kill: o kernel o encerra com SIGKILL, que a aplicação não consegue capturar nem registrar. Confundir isso com um bug da aplicação desperdiça tempo de depuração; confundir memória free com memória available leva a falsos alarmes ou a alarmes perdidos.

Como aplicar

• Leia free -h e baseie-se em available, não em free; um valor pequeno de free com um valor grande de available é normal e não é problema.
• Verifique o uso de swap e se há swap configurado (swapon --show); um sistema sem swap tem menos tempo de aviso antes de o OOM killer entrar em ação.
• Após a morte inexplicada de um serviço, consulte journalctl -k | grep -i "out of memory" ou dmesg | grep -i oom para encontrar um registro de encerramento que indique o processo e sua pontuação.
• Defina OOMScoreAdjust=-500 (ou valor semelhante) na seção [Service] de uma unidade systemd para um processo que deve ser o último a ser encerrado, e um valor positivo para um job em lote descartável que deve ser o primeiro.
• Defina MemoryMax= em serviços com consumo máximo de memória conhecido, para que um vazamento em um serviço não prive de memória os demais serviços do mesmo host; verifique com systemctl show <unit> -p MemoryMax -p OOMScoreAdjust.

Armadilhas

• Tratar toda morte de processo como bug de código antes de consultar o log do kernel em busca de um registro de OOM.
• Definir OOMScoreAdjust=-1000 (na prática, imune ao OOM) em um serviço, que então esconde um vazamento real ao transferir o encerramento para outro processo, em vez de expor o problema.
• Esquecer que MemoryMax= provoca um OOM kill no nível do cgroup sobre os próprios processos do serviço, que no dmesg é idêntico a um OOM kill do sistema inteiro, mas tem uma causa diferente e mais restrita.