Servidor Linux sem memória? Como tunar o OOM Killer e a swapiness

Por que o Linux decide matar os seus processos favoritos

Quando um servidor Linux atinge o limite máximo de memória física e o espaço de troca em disco também se esgota, o sistema entra em colapso operacional imediato. Para evitar que a máquina inteira trave completamente ou corrompa o sistema de arquivos, entra em cena um mecanismo drástico chamado Out of Memory (OOM) Killer. Na prática, esse componente do núcleo do sistema operacional escolhe um processo para ser encerrado à força e liberar RAM instantaneamente. O problema é que o critério padrão do sistema nem sempre é inteligente: muitas vezes ele derruba justamente o banco de dados principal ou a aplicação web mais importante em vez de um processo secundário inofensivo. Para evitar esse tipo de desastre em produção, precisamos entender como o sistema toma essa decisão e como podemos intervir diretamente para proteger nossos serviços mais valiosos.

Como o kernel calcula quem deve morrer primeiro

O kernel atribui a cada processo em execução um valor numérico chamado badness score, que representa a probabilidade daquele programa ser o escolhido no próximo evento de falta de memória. Quanto maior for essa pontuação, mais prioritário será o encerramento do processo quando a RAM acabar. Esse cálculo leva em consideração a quantidade exata de memória que o aplicativo está consumindo naquele momento e privilégios do usuário executor. Processos iniciados por usuários comuns costumam acumular mais pontos de risco do que serviços vitais rodando sob o usuário root. No entanto, o algoritmo automático do sistema operacional não conhece o contexto de negócio da sua infraestrutura, tratando um processo de cache secundário exatamente da mesma forma que trataria uma ferramenta de monitoramento como a que discutimos ao ver como tunar triggers no Zabbix. Por isso, confiar cegamente nas configurações padrão é um risco desnecessário para qualquer arquitetura robusta.

Ajustando a prioridade com o oom_score_adj

A ferramenta mais eficiente que temos para controlar esse comportamento é o arquivo oom_score_adj, localizado dentro do diretório de cada processo em /proc. Esse parâmetro aceita valores que vão de menos mil (-1000) até mil (1000). Quando configuramos um processo com o valor mínimo de menos mil, instruímos o kernel a dar imunidade absoluta a ele, tornando-o intocável pelo OOM Killer sob nenhuma circunstância. Por outro lado, valores positivos elevam drasticamente a prioridade de abate daquele programa específico. Essa estratégia de ajuste fino é comparável ao rigor técnico necessário quando diagnosticamos problemas complexos de hardware, similar a como rastrear curtos em placas com segurança para evitar danos irreversíveis ao circuito. Ao isolar serviços críticos, garantimos que tarefas secundárias sacrifiquem seus recursos antes de afetar o ecossistema principal.

Para aplicar essa configuração de forma definitiva em serviços gerenciados pelo systemd, podemos adicionar diretivas específicas no arquivo de configuração da unidade. Veja abaixo um exemplo prático de como blindar um serviço crítico inserindo a linha de ajuste diretamente na seção de serviço do systemd:

[Service]
ExecStart=/usr/local/bin/meu-servico-critico
OOMScoreAdjust=-900

Essa modificação simples garante que, mesmo sob extrema pressão de carga e escassez severa de memória, o seu serviço prioritário será o último a sofrer qualquer tipo de interrupção forçada pelo sistema operacional.

Controlando a agressividade da swap com a swapiness

Outro fator determinante na gestão de memória do Linux é o parâmetro vm.swappiness, que define com quanta frequência o kernel deve mover dados inativos da memória RAM para a área de swap no disco. O valor padrão na maioria das distribuições costuma ser sessenta, o que significa que o sistema começa a descarregar dados para o disco muito antes da RAM estar totalmente cheia. Em servidores modernos com alta capacidade de memória e discos SSD rápidos, um valor tão alto pode introduzir latências desnecessárias nas aplicações. Reduzir a swapiness para valores entre dez e vinte força o kernel a priorizar a retenção de dados ativos na memória física, acionando o disco apenas em situações de real necessidade. Essa sintonia fina evita que o sistema comece a sofrer lentidões inexplicáveis decorrentes do alto volume de operações de leitura e escrita na área de troca, mantendo a performance da aplicação estável e previsível.

Para verificar o valor atual da swapiness no seu servidor e alterá-lo de forma imediata sem precisar reiniciar a máquina, utilize os comandos apresentados na sequência abaixo:

1. Consulte o valor atual executando o comando para ler o arquivo de configuração do kernel.

2. cat /proc/sys/vm/swappiness
   

3. Altere o parâmetro dinamicamente para o novo valor desejado utilizando o comando sysctl.

4. sudo sysctl vm.swappiness=10
   

5. Torne a alteração permanente editando o arquivo de configuração do sistema operacional.

6. echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.d/99-swappiness.conf
   

Conclusão e considerações finais

Gerenciar a escassez de recursos em ambientes Linux exige planejamento proativo e domínio sobre os mecanismos internos do kernel. O OOM Killer não precisa ser um inimigo imprevisível se soubermos direcionar suas decisões através do ajuste adequado de pontuação e prioridades. Combinar uma estratégia inteligente de proteção de processos com o gerenciamento equilibrado da memória swap garante estabilidade operacional e protege aplicações vitais contra quedas catastróficas inesperadas em momentos críticos.

Manter o controle sobre o consumo de hardware e refinar parâmetros do sistema operacional transforma administradores reativos em engenheiros preparados para qualquer cenário de alta carga. Implemente essas recomendações nos seus ambientes de homologação e produção, avalie o comportamento sob estresse e mantenha sua infraestrutura sempre resiliente e protegida.