Como Diagnosticar e Resolver OOM Killer Encerrando Processos do PHP-FPM em Servidores Linux

Se o seu site em WordPress cai de repente com erro 502 Bad Gateway no Nginx e volta a funcionar sozinho minutos depois, o kernel do Linux provavelmente matou seus processos do PHP-FPM por falta de memória RAM. Esse mecanismo se chama Out of Memory (OOM) Killer. Ele não avisa no painel do WordPress nem grava erro detalhado no arquivo de log do PHP. Para resolver isso sem ficar chutando configurações, você precisa entender como o kernel escolhe o processo que vai derrubar e como dimensionar seu pool de processos de acordo com a memória real do servidor. Você pode ver mais sobre nossa abordagem em Otimização de Sites e Servidores.

O que você vai encontrar neste guia

• 1. Como o OOM Killer escolhe o PHP-FPM para derrubar
• 2. Como checar nos logs se foi mesmo o OOM Killer
• 3. A conta exata para definir o pm.max_children
• 4. Por que aumentar o memory_limit piora o problema
• 5. Ajustes práticos de swap e kernel no sysctl.conf
• 6. Como podemos resolver isso no seu servidor

1. Como o OOM Killer escolhe o PHP-FPM para derrubar

O Linux gerencia a memória física através de páginas. Quando os processos pedem mais memória do que o servidor tem sobrando e o espaço de swap também se esgota, o kernel precisa tomar uma decisão rápida para a máquina inteira não travar. Essa rotina fica no arquivo mm/oom_kill.c do código do kernel.

O kernel calcula uma nota chamada oom_score para cada programa em execução. Quanto mais memória o processo estiver segurando, maior a nota dele. Em servidores web rodando WordPress com WooCommerce ou plugins pesados, cada worker do PHP-FPM pode ocupar facilmente entre 100 MB e 200 MB. Quando você recebe 30 ou 50 acessos ao mesmo tempo, a soma de todos os workers passa da RAM disponível. Como o conjunto do PHP-FPM é quem está consumindo a maior fatia, o kernel manda um sinal SIGKILL direto para ele.

2. Como checar nos logs se foi mesmo o OOM Killer

O log de erro do Nginx só mostra que a conexão foi fechada antes do tempo (upstream prematurely closed connection). O PHP-FPM também não consegue registrar nada, porque o sinal SIGKILL encerra o processo na hora, sem chance de executar funções de desligamento.

Para ver a verdade, você precisa olhar o buffer de mensagens do kernel. Abra o terminal do servidor e rode:

dmesg -T | grep -i -E "oom|killed process|out of memory"

Se o OOM Killer tiver atuado, você verá linhas parecidas com estas:

[Wed Oct 01 19:15:22 2026] Out of memory: Kill process 28410 (php-fpm) score 684 or sacrifice child
[Wed Oct 01 19:15:22 2026] Killed process 28410 (php-fpm) total-vm:389120kB, anon-rss:148200kB

Isso confirma que o processo número 28410 foi finalizado com 148 MB de memória alocada porque a máquina física não tinha mais espaço livre.

3. A conta exata para definir o pm.max_children

A única forma de impedir que o OOM Killer volte a derrubar o PHP é colocar um teto rígido no número de workers permitidos. Essa configuração fica no arquivo do seu pool (geralmente em /etc/php/8.3/fpm/pool.d/www.conf).

Primeiro, descubra quanto de RAM cada worker do seu PHP gasta em média. Rode este comando no terminal:

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf "Média por worker: %.2f MB\n", sum/NR/1024 }'

Agora faça a conta:

• Pegue a memória RAM total do servidor (exemplo: 16 GB).
• Subtraia a memória que o MySQL precisa (exemplo: 6 GB no InnoDB Buffer Pool).
• Subtraia a memória do Redis e do sistema operacional (exemplo: 2 GB).
• Sobram 8 GB (8.192 MB) livres exclusivamente para o PHP.
• Divida esses 8.192 MB pelo gasto médio de cada worker (se for 120 MB: 8192 / 120 = 68).

Nesse servidor, o valor de pm.max_children não pode passar de 68. Se você colocar 120 achando que vai aguentar mais visitas, o servidor vai cair toda vez que tiver um pico de tráfego.

4. Por que aumentar o memory_limit piora o problema

Muita gente tenta resolver esse problema subindo o memory_limit no php.ini de 256M para 512M ou 1024M. Isso não resolve nada. O memory_limit não adiciona memória ao servidor, ele só autoriza que um único script gaste mais se precisar.

Se você tem um plugin que vaza memória e autoriza ele a gastar 512 MB, bastam 16 requisições simultâneas para comer 8 GB de RAM de uma vez só. O servidor cai ainda mais rápido. O segredo é manter o memory_limit no menor valor que seu site precisa para funcionar e colocar limites firmes no pm.max_children.

5. Ajustes práticos de swap e kernel no sysctl.conf

Além de calibrar o PHP-FPM, você deve configurar o comportamento de memória virtual do Linux no arquivo /etc/sysctl.conf:

# Faz o Linux evitar usar swap a menos que seja realmente necessário
vm.swappiness = 10

# Garante que o kernel recicle caches de arquivos com boa frequência
vm.vfs_cache_pressure = 50

Também configure a diretiva pm.max_requests = 500 no pool do PHP. Isso faz o PHP descartar cada worker depois de atender 500 requisições e abrir um processo limpo no lugar, limpando qualquer vazamento de memória acumulado por plugins antigos. Para melhorar ainda mais o tempo de resposta, nós recomendamos serviços como nossa Consultoria de SEO Técnico e ajustes nos indicadores do Core Web Vitals.

6. Como podemos resolver isso no seu servidor

Se você tem um e-commerce ou portal de notícias que não pode ficar caindo em dias de tráfego alto, o ideal é fazer uma revisão completa da sua pilha de servidores. Eu, Jonathan Pavão, trabalho ajustando Nginx, PHP-FPM, Redis e MySQL para operações que exigem estabilidade e velocidade máxima.