Visão Geral
Quando a memória física do ecossistema Linux atinge níveis críticos, o mecanismo OOM (Out of Memory) Killer entra em ação para preservar a integridade do kernel sacrificando processos. O utilitário choom oferece ao administrador controle refinado sobre essa lógica de descarte, permitindo consultar pontuações atuais, recalibrar prioridades e proteger tarefas essenciais contra encerramentos repentinos via terminal.
1. Fundamentos do utilitário choom e instalação de dependências
Antes de manipularmos as métricas de descarte do sistema operacional, precisamos garantir a presença dos pacotes essenciais util-linux e procps no ambiente de trabalho.

O binário choom atua diretamente sobre o parâmetro oom_score_adj gerenciado pelo kernel do Linux, métrica que define o peso de cada aplicação na fila de eliminação do OOM Killer.
Avaliando as opções disponíveis por meio do parâmetro --help, mapeamos os comandos fundamentais de operação:
⚙️ [Parâmetros principais]
-p, --pid : Especifica o identificador numérico (PID) da aplicação a ser inspecionada ou reconfigurada.-n, --adjust : Define o fator de ajuste aplicado à pontuação do OOM Killer (faixa válida de -1000 a 1000).-h, --help : Exibe o sumário com instruções e opções de uso da ferramenta.-V, --version : Informa a versão instalada do programa.

2. Inspecionando o valor de OOM Score em tarefas ativas
Para realizarmos os testes práticos de consulta e reajuste sem comprometer serviços de produção, iniciamos um processo temporário em segundo plano com durabilidade de 10 minutos executando sleep 600 &.

Capturamos o PID dessa rotina recém-criada na variável TARGET_PID para, em seguida, consultar seu fator de ajuste (oom_score_adj) com a flag choom -p.
Qualquer processo convencional inicializado sem modificações prévias herda a pontuação neutra padrão de 0.

Para validar se o diagnóstico do choom reflete fidedignamente o estado interno do kernel, lemos o arquivo virtual oom_score_adj exposto no diretório /proc.
A correspondência exata do número 0 valida que os parâmetros registrados no subsistema do kernel estão íntegros e consistentes.

3. Modificando a tolerância OOM de processos em execução
Elevamos a probabilidade de encerramento da nossa tarefa de teste atribuindo o índice 500 por meio do argumento -n, exigindo privilégios administrativos com sudo.
Valores positivos inseridos em oom_score_adj colocam a aplicação correspondente no topo da lista de descarte assim que o sistema apresentar exaustão de RAM.

Confirmamos a efetivação dessa nova política de memória disparando novamente a consulta via choom -p contra o PID monitorado.
O retorno do terminal demonstra que o índice migrou imediatamente do padrão 0 para 500, comprovando a atualização em tempo real sem necessidade de reiniciar o processo.

4. Inicialização de processos imunes ao OOM e limpeza do ambiente
Para blindar serviços de missão crítica contra qualquer término arbitrário pelo OOM Killer, podemos iniciá-los diretamente com o valor de compensação fixado no limite mínimo de -1000.
Ao aplicar -1000, o kernel entende que o processo possui prioridade máxima absoluta de sobrevivência, tornando-o imune a eliminações forçadas mesmo sob severa escassez de memória.

Isolamos o PID gerado nessa inicialização na variável TARGET_PID e executamos choom -p para checar a pontuação herdada na partida.
O resultado confirma que o valor -1000 entrou em vigor instantaneamente no momento da instanciação do comando.

Concluídas as validações, encerramos a rotina residual de background disparada nas etapas anteriores executando pkill -f 'sleep 600' || true.
Esse procedimento libera os descritores e a memória alocados durante os testes, mantendo o ecossistema limpo e sem resíduos operacionais.

Exploramos neste roteiro como o choom viabiliza tanto a inspeção rápida quanto a blindagem estratégica de processos sob a vigilância do OOM Killer.
Equilibre as pontuações de acordo com a criticidade de cada workload para manter seus servidores Linux resilientes mesmo diante de cenários extremos de esgotamento de memória.