Vazamento de memória

O vazamento é o incidente mais silencioso do catálogo. Nada dispara, nada transborda — um único processo em uma única máquina simplesmente deixa de devolver memória.

O que ele faz

A RAM de uma máquina sobe ao longo de minutos, não de segundos. Quando chega ao teto, o OOM killer começa a levar processos, o que por si só já é uma queda de serviço. Quando não resta mais nada para levar, a máquina vai para DOWN.

O detalhe importante é que isso é local. Afeta uma máquina e afeta a RAM — não a largura de banda, não o disco, não a frota.

A assinatura nos logs

O percentual de memória sobe primeiro no monit; quando chega ao teto, o kernel aciona o OOM killer. O registro do OOM diz quem invocou o killer, não o PID do processo que vaza:

02:41:08 web-02 monit[601]: 'web-02' mem usage of 80% matches resource limit [mem usage > 75.0%]
02:43:52 web-02 monit[601]: 'api-worker' mem usage of 38% matches resource limit [mem usage > 25.0%]
02:45:10 web-02 kernel: nginx invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0

free mostra o quadro geral, e top mostra qual processo está crescendo. Ordene a lista de processos pelo uso de memória; o processo que vaza pode não ser o nomeado no registro do OOM.

Se você deixar de lado

O OOM killer percorre a lista de processos em ordem, então você perde função peça por peça antes de perder a máquina. Como a máquina vai a CRIT e depois a DOWN, o custo de disponibilidade (uptime) não vem como uma penalidade separada, e sim pelo estado do servidor — mais a dívida de SLA depois que a janela de tolerância passa.

Como distingui-lo

Quando ele aparece