Saltar para o conteúdo 
Vou explicar o Pontuação OOM e o OOM Score Adjust como ferramentas de controlo concretas na gestão do alojamento: permitem definir quais os processos que o Linux OOM Killer encerra em caso de falta de memória e quais os que protege. Assim, mantenho o controlo quando RAM começa a escassear e assegura que os serviços essenciais continuem disponíveis online.
Pontos centrais
Para uma orientação rápida, vou resumir sucintamente as ideias mais importantes.
- Prioridade em caso de escassez: o OOM Score avalia qual o processo que deve ser encerrado em primeiro lugar.
- Controlo fino com oom_score_adj: de -1000 (proteger) a +1000 (sacrificar).
- Dinâmica em vez de um valor fixo: a avaliação varia consoante a carga e a configuração.
- Prática de acolhimento: Proteger os serviços críticos e, em caso dos serviços não críticos, encerrar os processos.
- Causas Resolver: verificar limites, Cgroups e planeamento da RAM.
Como funciona o OOM-Killer do Linux
Em caso de pressão de armazenamento o kernel do Linux decide quais os processos que vai encerrar para manter o sistema responsivo. Observo, nesse contexto, como o Kernel atribui a cada processo uma espécie de „gravidade“, que depende fortemente do consumo atual de memória. Se não houver uma quantidade suficiente de RAM ou de espaço livre na área de troca, o OOM-Killer intervém e encerra o processo com a classificação mais elevada. Este mecanismo evita a paralisação, mas não substitui um planeamento adequado da capacidade ao nível do anfitrião e dos serviços. Analiso a decisão no registo OOM e identifico se um serviço se destacou devido a um consumo excessivo de memória ou a uma configuração incorreta.
Compreender a pontuação OOM: dinâmica e escala
Verifico o Pontuação OOM de um processo em /proc/PID/oom_score e verifico assim o seu nível de risco atual. A escala vai, na prática, de 0 a 1000: quanto mais próximo de 1000, maior a probabilidade de o processo ser eliminado pelo «killer». Este valor representa um instantâneo, uma vez que os picos de carga, os limites do Cgroup e os tamanhos da cache estão em constante mudança. Por isso, nunca avalio a pontuação isoladamente, mas sim no contexto da memória RAM, do swap, do overcommit e dos processos paralelos. Quem analisa a pontuação regularmente reconhece padrões típicos e consegue antecipar gargalos antes que estes tirem os serviços de funcionamento.
Utilizar o OOM Score Adjust de forma específica
Com oom_score_adj Desloco ativamente a classificação de um processo entre -1000 e +1000. Se definir -1000, protejo totalmente o processo, enquanto valores positivos elevados o tornam deliberadamente passível de ser sacrificado. Escolho com moderação, pois demasiados processos protegidos limitam a margem de manobra do OOM-Killer. Os candidatos típicos para valores baixos são o SSH, o monitorização, os front-ends de proxy reverso e os controladores de bases de dados sensíveis. As tarefas em segundo plano, os relatórios ou os trabalhadores de curta duração recebem, em geral, um ajuste mais elevado, para que a interface do utilizador continue a responder quando a situação fica crítica.
Definir prioridades no alojamento
Em configurações produtivas, defino critérios claros Prioridades entre o front-end, a API, a base de dados e o processamento em lote. Primeiro, defino quais os serviços que têm de estar ativos do ponto de vista do utilizador e atribuo-lhes um ajuste OOM adequado. No systemd, para tal, defino OOMScoreAdjust= no ficheiro da unidade de serviço e documento a finalidade de cada valor. Quem já gere serviços através do systemd pode otimizar os processos; uma introdução a este tema pode ser encontrada em systemd na hospedagem. Desta forma, antecipo as falhas, em vez de as deixar ao acaso, e mantenho a experiência do utilizador online de forma fiável.
Cgroups, contentores e limites
Nunca me esquecerei da cgroups, pois os contentores e os serviços funcionam em ambientes de recursos próprios. Um processo com um OOM Score moderado pode, mesmo assim, encerrar-se se o seu Cgroup tiver um limite de memória restrito e ele o ultrapassar momentaneamente. Por isso, verifico os limites no Cgroup v2 e defino limites rígidos e flexíveis de acordo com os perfis de carga. Quem opera em multi-tenancy ou alojamento partilhado beneficia de quotas e contabilidade bem definidas; para mais informações, consulte cgroup v2 na hospedagem. Se a interação for a adequada, o ajuste do OOM e os limites funcionam como um par de parafusos de regulação bem sincronizados.
Diagnóstico e monitorização em caso de eventos OOM
Quando há uma explosão, preciso de informações claras Sinais e repetibilidade na análise. Analiso o dmesg, o journald e o /var/log/kern.log, guardo as linhas OOM e recolho o PID da vítima, juntamente com o oom_score e o oom_score_adj. Para verificações de rotina, utilizo scripts que listam os maiores consumidores de memória e acionam limiares de alerta. Quem quiser aprofundar o assunto encontrará uma abordagem estruturada no Análise do OOM-Killer. Em configurações permanentes, integro métricas como RSS, cache, swap-in/out e limites dos contentores na monitorização, para poder identificar tendências atempadamente.
Guia de referência em tabela para administradores
Utilizo o resumo seguinte como um resumo conciso Guia, quando dou prioridade às funções e documento os ajustes. A coluna „Justificação“ indica por que razão um serviço recebe proteção ou está disposto a fazer sacrifícios. Adapto os números ao projeto, mas a orientação ajuda a tomar decisões rápidas. Quem utiliza a tabela como ponto de partida ganha clareza nas análises pós-projeto e nas propostas de alteração. O importante é: mantenho sempre uma margem de segurança no sistema global, para que seja raramente necessário eliminar funções de forma drástica.
| Componente | Destino típico | Exemplo oom_score_adj | Motivo |
|---|---|---|---|
| SSH-Daemon | Atiradores | -500 a -900 | Garantir o acesso para intervenções, mesmo em situações de congestionamento. |
| Proxy reverso (nginx/HAProxy) | Atiradores | -300 a -700 | Atender ao tráfego de entrada, apresentar páginas de erro. |
| BD-Controlador/Instância primária | Atiradores | -200 a -600 | Manter as ligações, garantir o acesso aos dados. |
| PHP-FPM/Worker de aplicação | Neutro a disposto a fazer sacrifícios | 0 a +300 | É possível ter muitos workers em paralelo. |
| Processamento em lote/Cópias de segurança/Relatórios | Disposto a fazer sacrifícios | +300 a +800 | Pode ser adiado sem impacto para o utilizador. |
| Indexador/Consumidor da fila | Disposto a fazer sacrifícios | +200 a +600 | Pode fazer uma breve pausa e recuperar mais tarde. |
Limitar corretamente os workers do WordPress e do PHP
No WordPress, presto atenção ao seguinte: Trabalhador-Número, memory_limit e operações pesadas, como processamento de imagens ou importações. Configuro o PHP-FPM de forma a que o número de processos ativos se adapte à RAM e não provoque sobrecargas. Na base de dados, somo os tamanhos dos buffers e da cache e deixo uma margem de segurança, para que os picos de tráfego não bloqueiem tudo. Acompanho o OpCache, o cache de objetos e o otimizador de imagens, pois estes aumentam rapidamente o consumo de memória. Desta forma, garanto que picos de carga de curta duração não comprometam imediatamente os processos importantes do front-end.
Na prática: políticas e manuais de procedimentos
Mantenho a minha Políticas conciso e exequível, para que a equipa não hesite em caso de emergência. Isso inclui: definir candidatos a proteção, identificar papéis de vítimas, atribuir OOMScoreAdjust= às unidades do systemd e documentar os valores no repositório. Verifico o efeito com ferramentas e carga de teste até que a ordem dos sacrifícios corresponda aos objetivos. Em seguida, redijo um manual de procedimentos que descreve os registos, os alertas e as medidas iniciais. Desta forma, a reação mantém-se consistente, mesmo quando novos colegas assumem as funções.
# Exemplo de fragmento para uma unidade do systemd
[Service]
OOMScoreAdjust=-400
# Recarregar e reiniciar:
# systemctl daemon-reload && systemctl restart nginx
# Verificar em tempo real:
cat /proc/$(pidof nginx)/oom_score
cat /proc/$(pidof nginx)/oom_score_adj
# Aumentar/diminuir temporariamente (root):
echo 300 | sudo tee /proc//oom_score_adj
Erros frequentes e medidas corretivas
Muitos problemas surgem porque Limites Não se encaixam: demasiados workers PHP, caches da base de dados demasiado grandes e sem margem para picos de carga. Nessa altura, o OOM-Killer intervém regularmente, embora bastassem alguns ajustes. Começo por corrigir o número de workers, avalio o efeito e só aumento a RAM se a necessidade for claramente evidente. Definir muitos processos para -1000 também é prejudicial, pois o kernel precisa de liberdade de ação. Estabeleço prioridades com sensatez, para que o sistema possa reagir de forma ordenada em caso de emergência.
Overcommit, swap e níveis de memória
Apresento a minha Estratégia de overcommit de forma consciente, pois determina a rapidez com que um sistema entra na zona OOM. Com vm.overcommit_memory=0 (heurística), o sistema funciona frequentemente de forma estável, porque o kernel avalia o limite de overcommit com base na utilização e no histórico. A configuração torna-se mais rigorosa com vm.overcommit_memory=2 juntamente com vm.overcommit_ratio, que define a ocupação virtual máxima permitida. Quem definir vm.overcommit_memory=1 de forma genérica corre o risco de que as reservas de memória sejam bem-sucedidas, mas falhem redondamente mais tarde na alocação – um terreno fértil frequente para eventos OOM sob carga.
Eu calibro Troca de forma a proporcionar uma reserva, mas sem se tornar um fator que aumente a latência. Um valor moderado de vm.swappiness mantém a memória principal livre para os caminhos mais ativos, enquanto as páginas raramente utilizadas são transferidas para o swap. Posso utilizar o zswap ou o zram como uma reserva elástica quando a E/S está lenta – isto reduz o risco de OOM, mas consome CPU. Os níveis de memória também são importantes: o vm.min_free_kbytes deve ser suficientemente elevado para que o kernel possa recuperar memória atempadamente. Quem definir valores demasiado baixos força o sistema a realizar recuperações frenéticas e provoca comportamentos de caminho que conduzem a situações de OOM.
# Exemplo: overcommit conservador e swapping moderado
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=90
sysctl -w vm.swappiness=30
# Para testes, registar de forma persistente em /etc/sysctl.d/
Opções do Systemd para além do OOMScoreAdjust
Para além do OOMScoreAdjust, utilizo o systemd para Barreiras de contenção aplicar diretamente ao serviço. Com MemoryMax=, imponho um limite rígido (cgroup memory.max); MemoryHigh= reduz gradualmente a memória sob carga e MemorySwapMax= limita a troca de memória. MemoryLow= e MemoryMin= dão prioridade às partes em cache de um serviço em situações de pressão, para que os processos importantes não entrem em inatividade tão rapidamente. Juntamente com OOMPolicy=, controlo o que o systemd faz em caso de OOM ao nível da unidade (por exemplo, apenas parar o serviço ou encerrar todas as dependências). Em «Slices», agrupo funções — front-end web, processamento em lote, base de dados — e defino regras uniformes, para que casos isolados não desestabilizem o conjunto.
Constato que a proteção nunca é absoluta: mesmo os processos com -1000 podem ter de ceder em situações sem saída. Por isso, defino valores generosos, mas realistas Mínimos (MemoryLow/Min) apenas para muito poucos serviços essenciais e verifico se a soma de todas as alocações permanece abaixo da memória fisicamente disponível. Desta forma, evito que medidas de proteção bem-intencionadas ceguem o OOM-Killer.
Kubernetes e orquestração de contentores
Em arquiteturas como o Kubernetes, a lógica OOM atua em vários níveis. Eu utilizo Pedidos e Limites de forma a que os pods sejam classificados na classe de QoS pretendida: «Guaranteed» oferece a maior proteção, «Burstable» amortece os picos e «BestEffort» é o mais suscetível de ser afetado. O kubelet atribui automaticamente os valores de OOMScoreAdjust resultantes – por isso, planeio com base em especificações de recursos, em vez de valores de ajuste manuais nos contentores. Se um contentor atingir o seu `memory.limit`, é encerrado dentro do seu cgroup, mesmo que o anfitrião ainda tenha memória disponível; isto não é um OOM clássico do anfitrião, mas sim uma autodefesa específica do limite.
Tenho em conta proporções de memória nativa fora das configurações do heap (por exemplo, na JVM/Node), para que os contentores não entrem em colapso inesperadamente ao atingirem o limite. Além disso, calculo margens de segurança para os pods em caso de picos e planeio o overcommit dos nós apenas com moderação, para que as evicções sejam raras. Quando o cgroup v2 está ativo, utilizo o `memory.oom.group` de forma seletiva, para que, em caso de emergência, um grupo inteiro de processos seja encerrado de forma ordenada, em vez de deixar trabalhadores individuais num pod «zombie». Isto mantém o sistema limpo e a recuperação previsível.
Profundidade do diagnóstico: SMaps, PSI e testes reprodutíveis
Para análises aprofundadas, recorro a /proc-Informações e métricas de pressão. /proc/PID/status mostra VmRSS, VmSwap e threads; /proc/PID/smaps_rollup resume proporções como Anon, File e Shmem, sem me perder em pormenores. Assim, consigo perceber se o Page Cache está a induzir em erro ou se as páginas anónimas (conjunto de dados de trabalho real) estão a aumentar. Com /proc/pressure/memory, medo PSI-Sinais que indicam quanto tempo o sistema fica afetado por processos de recuperação ativos ou bloqueios. Estabeleço alertas para estes valores muito antes de ocorrer uma situação de OOM – o que é ideal para acionar automaticamente medidas corretivas (limitação de recursos, escalabilidade, redução do número de workers).
# Instantâneos relevantes
journalctl -k -g "Out of memory|oom-killer"
cat /proc/pressure/memory
grep -E "VmRSS|VmSwap|Threads" /proc//status
cat /proc//smaps_rollup
# Reproduzir OOM (ambiente de teste!)
stress-ng --vm 2 --vm-bytes 80% --timeout 30s
Casos especiais: JVM, Node.js e PHP em contentores
JVM-Os serviços requerem atenção, porque, além do heap, também é preciso ter em conta o metaspace, as pilhas de threads, os buffers diretos e o comportamento nativo do alocador. Eu faço uma gestão otimizada para contentores com o MaxRAMPercentage e defino um heap que deixe margem para estas componentes. Em situações de elevado paralelismo, limito os conjuntos de threads, pois muitas pilhas pequenas acumulam-se de forma prejudicial. Para Nó.js ajusto o parâmetro –max-old-space-size ao limite do contentor, para evitar encerramentos forçados. E no caso de PHP-FPM Calculo o pm.max_children com base na RAM, no consumo médio por pedido e no memory_limit – mais uma reserva para caches e servidores web. Desta forma, evito «avalanches» silenciosas que só se tornam visíveis nos picos de tráfego.
Eu guardo o Estratégia de alocação Em destaque: a glibc com muitas arenas pode fragmentar a memória e aumentar o consumo de memória em cargas de trabalho com muitos threads. Para determinados serviços, o jemalloc ou o tcmalloc proporcionam picos mais consistentes; estou a testar isto de forma específica, a documentar o efeito e a implementá-lo de forma controlada. Além disso, limito os diretórios tmpfs no contentor, para que os uploads ou ficheiros temporários não consumam a RAM sem que se perceba.
Tmpfs, Huge Pages e cache de páginas
tmpfs É algo que muitas vezes passa despercebido: sem um limite de tamanho, ocupa cada vez mais espaço até atingir uma parte da RAM e, de repente, falta espaço noutros locais. Eu monto os tmpfs com um valor «size=» definido, especialmente em percursos de compilação ou de upload. Páginas enormes transparentes (THP) A fragmentação e a latência têm influência; para serviços em que a latência é crítica, utilizo frequentemente o „madvise“, para que apenas as alocações adequadas beneficiem. O KSM permite a deduplicação e poupa espaço de armazenamento, mas consome recursos da CPU – é útil em máquinas de desenvolvimento; em percursos de desempenho, verifico o impacto e a sobrecarga.
O Cache de páginas não é memória „desperdiçada“; acelera as operações de E/S. Se a liberte de forma demasiado agressiva ou utilize caches de descarte como medida permanente, estou a transferir os custos para picos de latência. É preferível definir metas de memória por função e impor uma relação equitativa através de mecanismos cgroup (memory.high / memory.max). Desta forma, os conjuntos ativos dos serviços importantes permanecem na RAM e as situações de OOM tornam-se mais raras.
Resumo para a vida quotidiana
Eu uso o Pontuação OOM como barómetro de risco e ajusto, com o oom_score_adj, a ordem correta das vítimas. Protejo os serviços que afetam os utilizadores, coloco as tarefas que podem ser adiadas na lista de vítimas e documento cada valor de forma compreensível. Planeio os limites do cgroup, o número de trabalhadores e os tamanhos da cache como um todo, para que os picos não se transformem num incêndio generalizado. Os registos, a monitorização e um pequeno manual de procedimentos garantem que detecte rapidamente os eventos OOM e os resolva de forma direcionada. Com esta disciplina, o host mantém-se fiável e evito surpresas desagradáveis durante as noites de produção.
