{"id":2243,"date":"2026-10-01T21:55:30","date_gmt":"2026-10-02T00:55:30","guid":{"rendered":"https:\/\/www.especialistadeseo.com.br\/blog\/como-diagnosticar-e-resolver-oom-killer-encerrando-processos-do-php-fpm-em-servidores-linux\/"},"modified":"2026-10-01T21:55:30","modified_gmt":"2026-10-02T00:55:30","slug":"como-diagnosticar-e-resolver-oom-killer-encerrando-processos-do-php-fpm-em-servidores-linux","status":"publish","type":"post","link":"https:\/\/www.especialistadeseo.com.br\/blog\/como-diagnosticar-e-resolver-oom-killer-encerrando-processos-do-php-fpm-em-servidores-linux\/","title":{"rendered":"Como Diagnosticar e Resolver OOM Killer Encerrando Processos do PHP-FPM em Servidores Linux"},"content":{"rendered":"\n\n<p class=\"lead wp-block-paragraph\">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\u00f3ria RAM. Esse mecanismo se chama Out of Memory (OOM) Killer. Ele n\u00e3o avisa no painel do WordPress nem grava erro detalhado no arquivo de log do PHP. Para resolver isso sem ficar chutando configura\u00e7\u00f5es, voc\u00ea precisa entender como o kernel escolhe o processo que vai derrubar e como dimensionar seu pool de processos de acordo com a mem\u00f3ria real do servidor. Voc\u00ea pode ver mais sobre nossa abordagem em <a href=\"https:\/\/www.especialistadeseo.com.br\/otimizacao-de-sites.php\">Otimiza\u00e7\u00e3o de Sites e Servidores<\/a>.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full featured-article-image\"><img loading=\"lazy\" decoding=\"async\" width=\"1200\" height=\"675\" src=\"https:\/\/www.especialistadeseo.com.br\/blog\/wp-content\/uploads\/2026\/10\/post_1_Como_Diagnosticar_e_Resolver_O-1.jpg\" alt=\"Diagn\u00f3stico t\u00e9cnico de OOM Killer no PHP-FPM em servidores Linux\" class=\"wp-image-2242\" srcset=\"https:\/\/www.especialistadeseo.com.br\/blog\/wp-content\/uploads\/2026\/10\/post_1_Como_Diagnosticar_e_Resolver_O-1.jpg 1200w, https:\/\/www.especialistadeseo.com.br\/blog\/wp-content\/uploads\/2026\/10\/post_1_Como_Diagnosticar_e_Resolver_O-1-300x169.jpg 300w, https:\/\/www.especialistadeseo.com.br\/blog\/wp-content\/uploads\/2026\/10\/post_1_Como_Diagnosticar_e_Resolver_O-1-1024x576.jpg 1024w, https:\/\/www.especialistadeseo.com.br\/blog\/wp-content\/uploads\/2026\/10\/post_1_Como_Diagnosticar_e_Resolver_O-1-768x432.jpg 768w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><figcaption>An\u00e1lise de logs de kernel e dimensionamento de mem\u00f3ria para PHP-FPM.<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">O que voc\u00ea vai encontrar neste guia<\/h2>\n\n\n\n<ul class=\"toc-list wp-block-list\">\n    <li><a href=\"#como-funciona-oom\">1. Como o OOM Killer escolhe o PHP-FPM para derrubar<\/a><\/li>\n    <li><a href=\"#checando-os-logs\">2. Como checar nos logs se foi mesmo o OOM Killer<\/a><\/li>\n    <li><a href=\"#calculando-max-children\">3. A conta exata para definir o pm.max_children<\/a><\/li>\n    <li><a href=\"#o-erro-do-memory-limit\">4. Por que aumentar o memory_limit piora o problema<\/a><\/li>\n    <li><a href=\"#ajustes-no-kernel\">5. Ajustes pr\u00e1ticos de swap e kernel no sysctl.conf<\/a><\/li>\n    <li><a href=\"#como-podemos-ajudar\">6. Como podemos resolver isso no seu servidor<\/a><\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"como-funciona-oom\">1. Como o OOM Killer escolhe o PHP-FPM para derrubar<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">O Linux gerencia a mem\u00f3ria f\u00edsica atrav\u00e9s de p\u00e1ginas. Quando os processos pedem mais mem\u00f3ria do que o servidor tem sobrando e o espa\u00e7o de swap tamb\u00e9m se esgota, o kernel precisa tomar uma decis\u00e3o r\u00e1pida para a m\u00e1quina inteira n\u00e3o travar. Essa rotina fica no arquivo <code>mm\/oom_kill.c<\/code> do c\u00f3digo do kernel.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">O kernel calcula uma nota chamada <code>oom_score<\/code> para cada programa em execu\u00e7\u00e3o. Quanto mais mem\u00f3ria 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\u00ea recebe 30 ou 50 acessos ao mesmo tempo, a soma de todos os workers passa da RAM dispon\u00edvel. Como o conjunto do PHP-FPM \u00e9 quem est\u00e1 consumindo a maior fatia, o kernel manda um sinal <code>SIGKILL<\/code> direto para ele.<\/p>\n\n\n\n<div class=\"cta-incontent-box\" style=\"background: linear-gradient(180deg, #18181b 0%, #121217 100%); border: 1px solid #3f3f46; border-left: 4px solid #3b82f6; border-radius: 6px; padding: 1.75rem; margin: 2.5rem 0; box-shadow: 0 10px 25px rgba(0,0,0,0.3);\">\n    <h4 style=\"color: #ffffff; font-size: 1.15rem; margin-top: 0; margin-bottom: 0.5rem;\">\n        Seu site est\u00e1 caindo com erro 502 em hor\u00e1rios de pico?\n    <\/h4>\n    <p style=\"color: #d4d4d8; font-size: 0.95rem; line-height: 1.6; margin-bottom: 1.25rem;\">\n        Quedas intermitentes que somem sozinhas quase sempre s\u00e3o causadas pelo OOM Killer. N\u00f3s analisamos a mem\u00f3ria de cada thread do seu servidor e corrigimos a configura\u00e7\u00e3o.\n    <\/p>\n    <button onclick=\"showModal()\" class=\"btn-solid\" style=\"background-color: #ffffff; color: #09090b; border: none; padding: 0.75rem 1.5rem; font-weight: 600; font-size: 0.9rem; border-radius: 4px; cursor: pointer;\">\n        Solicitar an\u00e1lise do meu servidor &rarr;\n    <\/button>\n<\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"checando-os-logs\">2. Como checar nos logs se foi mesmo o OOM Killer<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">O log de erro do Nginx s\u00f3 mostra que a conex\u00e3o foi fechada antes do tempo (<code>upstream prematurely closed connection<\/code>). O PHP-FPM tamb\u00e9m n\u00e3o consegue registrar nada, porque o sinal <code>SIGKILL<\/code> encerra o processo na hora, sem chance de executar fun\u00e7\u00f5es de desligamento.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para ver a verdade, voc\u00ea precisa olhar o buffer de mensagens do kernel. Abra o terminal do servidor e rode:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>dmesg -T | grep -i -E \"oom|killed process|out of memory\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Se o OOM Killer tiver atuado, voc\u00ea ver\u00e1 linhas parecidas com estas:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[Wed Oct 01 19:15:22 2026] Out of memory: Kill process 28410 (php-fpm) score 684 or sacrifice child\n[Wed Oct 01 19:15:22 2026] Killed process 28410 (php-fpm) total-vm:389120kB, anon-rss:148200kB<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Isso confirma que o processo n\u00famero 28410 foi finalizado com 148 MB de mem\u00f3ria alocada porque a m\u00e1quina f\u00edsica n\u00e3o tinha mais espa\u00e7o livre.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"calculando-max-children\">3. A conta exata para definir o pm.max_children<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A \u00fanica forma de impedir que o OOM Killer volte a derrubar o PHP \u00e9 colocar um teto r\u00edgido no n\u00famero de workers permitidos. Essa configura\u00e7\u00e3o fica no arquivo do seu pool (geralmente em <code>\/etc\/php\/8.3\/fpm\/pool.d\/www.conf<\/code>).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Primeiro, descubra quanto de RAM cada worker do seu PHP gasta em m\u00e9dia. Rode este comando no terminal:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps --no-headers -o \"rss,cmd\" -C php-fpm | awk '{ sum+=$1 } END { printf \"M\u00e9dia por worker: %.2f MB\\n\", sum\/NR\/1024 }'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Agora fa\u00e7a a conta:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n    <li>Pegue a mem\u00f3ria RAM total do servidor (exemplo: 16 GB).<\/li>\n    <li>Subtraia a mem\u00f3ria que o MySQL precisa (exemplo: 6 GB no InnoDB Buffer Pool).<\/li>\n    <li>Subtraia a mem\u00f3ria do Redis e do sistema operacional (exemplo: 2 GB).<\/li>\n    <li>Sobram 8 GB (8.192 MB) livres exclusivamente para o PHP.<\/li>\n    <li>Divida esses 8.192 MB pelo gasto m\u00e9dio de cada worker (se for 120 MB: <code>8192 \/ 120 = 68<\/code>).<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Nesse servidor, o valor de <code>pm.max_children<\/code> n\u00e3o pode passar de <strong>68<\/strong>. Se voc\u00ea colocar 120 achando que vai aguentar mais visitas, o servidor vai cair toda vez que tiver um pico de tr\u00e1fego.<\/p>\n\n\n\n<div class=\"cta-incontent-box\" style=\"background: linear-gradient(180deg, #18181b 0%, #121217 100%); border: 1px solid #3f3f46; border-left: 4px solid #f59e0b; border-radius: 6px; padding: 1.75rem; margin: 2.5rem 0; box-shadow: 0 10px 25px rgba(0,0,0,0.3);\">\n    <h4 style=\"color: #ffffff; font-size: 1.15rem; margin-top: 0; margin-bottom: 0.5rem;\">\n        Precisa de ajuda para calcular os limites do seu servidor?\n    <\/h4>\n    <p style=\"color: #d4d4d8; font-size: 0.95rem; line-height: 1.6; margin-bottom: 1.25rem;\">\n        Configurar esses n\u00fameros errado em produ\u00e7\u00e3o pode travar o banco de dados ou deixar o site fora do ar. Veja como funciona nossa <a href=\"https:\/\/www.especialistadeseo.com.br\/auditoria-tecnica.php\" style=\"color: #60a5fa; text-decoration: underline;\">Auditoria T\u00e9cnica<\/a>.\n    <\/p>\n    <button onclick=\"showModal()\" class=\"btn-solid\" style=\"background-color: #ffffff; color: #09090b; border: none; padding: 0.75rem 1.5rem; font-weight: 600; font-size: 0.9rem; border-radius: 4px; cursor: pointer;\">\n        Agendar auditoria t\u00e9cnica &rarr;\n    <\/button>\n<\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"o-erro-do-memory-limit\">4. Por que aumentar o memory_limit piora o problema<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Muita gente tenta resolver esse problema subindo o <code>memory_limit<\/code> no <code>php.ini<\/code> de 256M para 512M ou 1024M. Isso n\u00e3o resolve nada. O <code>memory_limit<\/code> n\u00e3o adiciona mem\u00f3ria ao servidor, ele s\u00f3 autoriza que um \u00fanico script gaste mais se precisar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Se voc\u00ea tem um plugin que vaza mem\u00f3ria e autoriza ele a gastar 512 MB, bastam 16 requisi\u00e7\u00f5es simult\u00e2neas para comer 8 GB de RAM de uma vez s\u00f3. O servidor cai ainda mais r\u00e1pido. O segredo \u00e9 manter o <code>memory_limit<\/code> no menor valor que seu site precisa para funcionar e colocar limites firmes no <code>pm.max_children<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ajustes-no-kernel\">5. Ajustes pr\u00e1ticos de swap e kernel no sysctl.conf<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Al\u00e9m de calibrar o PHP-FPM, voc\u00ea deve configurar o comportamento de mem\u00f3ria virtual do Linux no arquivo <code>\/etc\/sysctl.conf<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Faz o Linux evitar usar swap a menos que seja realmente necess\u00e1rio\nvm.swappiness = 10\n\n# Garante que o kernel recicle caches de arquivos com boa frequ\u00eancia\nvm.vfs_cache_pressure = 50<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tamb\u00e9m configure a diretiva <code>pm.max_requests = 500<\/code> no pool do PHP. Isso faz o PHP descartar cada worker depois de atender 500 requisi\u00e7\u00f5es e abrir um processo limpo no lugar, limpando qualquer vazamento de mem\u00f3ria acumulado por plugins antigos. Para melhorar ainda mais o tempo de resposta, n\u00f3s recomendamos servi\u00e7os como nossa <a href=\"https:\/\/www.especialistadeseo.com.br\/seo-tecnico.php\">Consultoria de SEO T\u00e9cnico<\/a> e ajustes nos indicadores do <a href=\"https:\/\/www.especialistadeseo.com.br\/core-web-vitals.php\">Core Web Vitals<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"como-podemos-ajudar\">6. Como podemos resolver isso no seu servidor<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Se voc\u00ea tem um e-commerce ou portal de not\u00edcias que n\u00e3o pode ficar caindo em dias de tr\u00e1fego alto, o ideal \u00e9 fazer uma revis\u00e3o completa da sua pilha de servidores. Eu, <strong>Jonathan Pav\u00e3o<\/strong>, trabalho ajustando Nginx, PHP-FPM, Redis e MySQL para opera\u00e7\u00f5es que exigem estabilidade e velocidade m\u00e1xima.<\/p>\n\n\n\n<div class=\"cta-incontent-box\" style=\"background: linear-gradient(180deg, #18181b 0%, #121217 100%); border: 1px solid #3f3f46; border-left: 4px solid #22c55e; border-radius: 6px; padding: 1.75rem; margin: 2.5rem 0; box-shadow: 0 10px 25px rgba(0,0,0,0.3);\">\n    <h4 style=\"color: #ffffff; font-size: 1.15rem; margin-top: 0; margin-bottom: 0.5rem;\">\n        Fale diretamente comigo pelo WhatsApp\n    <\/h4>\n    <p style=\"color: #d4d4d8; font-size: 0.95rem; line-height: 1.6; margin-bottom: 1.25rem;\">\n        Vamos analisar o que est\u00e1 derrubando seu servidor e deixar sua infraestrutura r\u00e1pida e est\u00e1vel.\n    <\/p>\n    <button onclick=\"showModal()\" class=\"btn-solid\" style=\"background-color: #25D366; color: #ffffff; border: none; padding: 0.85rem 1.75rem; font-weight: 600; font-size: 0.95rem; border-radius: 4px; cursor: pointer;\">\n        Conversar no WhatsApp agora &rarr;\n    <\/button>\n<\/div>\n\n","protected":false},"excerpt":{"rendered":"<p>Se o seu site em WordPress cai de repente com erro 502 Bad Gateway no Nginx e volta a funcionar sozinho minutos depois, o&#8230;<\/p>\n","protected":false},"author":1,"featured_media":2242,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2243","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress-e-infraestrutura"],"_links":{"self":[{"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/posts\/2243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/comments?post=2243"}],"version-history":[{"count":0,"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/posts\/2243\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/media\/2242"}],"wp:attachment":[{"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/media?parent=2243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/categories?post=2243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.especialistadeseo.com.br\/blog\/wp-json\/wp\/v2\/tags?post=2243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}