OOM Killer: Como Evitar e Otimizar a Memória do Servidor Linux

By HelpSysAdminMonitoramento e Troubleshooting (Diagnóstico)

O OOM Killer (Out of Memory Killer) é um mecanismo do kernel do Linux que entra em ação quando o sistema esgota sua memória RAM e Swap. Para evitar que o sistema inteiro trave (kernel panic), ele sacrifica processos específicos para liberar memória.

Se você está lidando com isso em ambientes de alta performance como os que gerencia, aqui estão as estratégias principais para domar o OOM Killer:

1. Otimização de Aplicações Críticas

Antes de mexer no kernel, o foco deve ser nos “comilões” de memória:

  • MySQL/MariaDB: Ajuste o innodb_buffer_pool_size. Em servidores com 64GB de RAM, ele não deve ocupar 100% da memória; deixe margem para o sistema (geralmente setar em 70-80% da RAM disponível).
  • PHP-FPM: Limite o pm.max_children. Cada processo PHP consome uma fatia considerável; se você tiver muitos processos simultâneos, a memória vai evaporar rapidamente.
  • LiteSpeed/Apache: Verifique os limites de conexões simultâneas para evitar o empilhamento de processos.

2. Ajuste do “Overcommit” do Kernel

O Linux, por padrão, permite que processos solicitem mais memória do que realmente existe fisicamente (overcommit). Você pode tornar o kernel mais “conservador”.

Edite o arquivo /etc/sysctl.conf:

Bash

# Define como o kernel lida com overcommit
# 2 = Não permite overcommit acima de uma porcentagem da RAM + Swap
vm.overcommit_memory = 2
# Define a porcentagem de RAM a ser usada no cálculo acima
vm.overcommit_ratio = 80
  • Atenção: Isso pode fazer com que processos falhem ao iniciar se não houver memória “prometida” disponível, mas evita que o OOM Killer precise matar processos em execução.

3. Priorização de Processos (OOM Score)

Você pode dizer ao kernel: “Se precisar matar alguém, não mate o MySQL”. Cada processo tem um valor chamado oom_score_adj (de -1000 a 1000). Quanto menor o valor, menor a chance de ser morto.

Para proteger o MariaDB, por exemplo:

Bash

# Protege o processo (substitua pelo PID real)
echo -1000 > /proc/$(pidof mariadbd)/oom_score_adj

Dica: Você pode automatizar isso via Systemd adicionando OOMScoreAdjust=-1000 na unit do serviço.

4. Gestão de Swap e Zram

Em servidores modernos, o Swap em disco (SSD/NVMe) é uma rede de segurança, mas o Zram (Swap comprimido na RAM) é muito mais eficiente para evitar latência extrema antes do OOM Killer agir.

  • Mantenha o vm.swappiness entre 10 e 30 para servidores de banco de dados, garantindo que o sistema use a RAM física o máximo possível, mas tenha onde “respirar” se necessário. Edite nano /etc/sysctl.conf e insira vm.swappiness= 10. Saia do editor e execute sysctl -p para ativar as alterações.

5. Monitoramento Proativo

O segredo para evitar o OOM Killer é saber que ele está chegando.

  • CloudLinux: Utilize o LVE Manager para limitar a memória por usuário/conta, evitando que um único site derrube o servidor inteiro.
  • Alertas: Configure o monitoramento (Zabbix, Netdata ou Grafana) para alertar quando a memória livre (incluindo buffers/cache) cair abaixo de 10%.

Veja Mais:

AlmaLinux em Produção: Guia de Boas Práticas e Segurança 2026
Fail2Ban vs CrowdSec em Produção: Qual é a Melhor Solução de Segurança para Servidores Linux?
Como Funciona um Servidor Linux em Produção: Do Boot aos Serviços Ativos
Infraestrutura como Produto: Transformando TI em Ativo Estratégico
Timeouts mal configurados e seu impacto real em produção
Load Average e CPU Usage: Qual a Diferença e Como Analisar?