{"id":17358,"date":"2026-02-05T11:52:30","date_gmt":"2026-02-05T10:52:30","guid":{"rendered":"https:\/\/webhosting.de\/wordpress-php-fpm-children-blockieren-optimierungstuning-serverperf\/"},"modified":"2026-02-05T11:52:30","modified_gmt":"2026-02-05T10:52:30","slug":"wordpress-php-fpm-children-block-otimizacao-tuning-serverperf","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/wordpress-php-fpm-children-blockieren-optimierungstuning-serverperf\/","title":{"rendered":"WordPress PHP-FPM Crian\u00e7as: Valores incorretos bloqueiam p\u00e1ginas"},"content":{"rendered":"<p><strong>PHP-FPM Crian\u00e7as<\/strong> decidem no WordPress se os pedidos correm bem ou ficam retidos na fila de espera. Vou mostrar-lhe como os pedidos incorrectos <strong>pm.max_children<\/strong>-Os valores bloqueiam p\u00e1ginas, consomem RAM e a forma como calculo valores limpos.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Antes de me aprofundar mais, vou resumir brevemente as mensagens principais:<\/p>\n<ul>\n  <li><strong>pm.max_children<\/strong> determina quantos pedidos simult\u00e2neos de PHP est\u00e3o a ser executados.<\/li>\n  <li><strong>Demasiado pouco<\/strong> As crian\u00e7as geram filas de espera, 502\/504 e TTFB elevado.<\/li>\n  <li><strong>Demasiado<\/strong> conduz a estrangulamentos na RAM, a trocas e a mortes OOM.<\/li>\n  <li><strong>F\u00f3rmula<\/strong>RAM PHP dispon\u00edvel \/ tamanho do processo \u00d7 0,7-0,8.<\/li>\n  <li><strong>Iterativo<\/strong> A afina\u00e7\u00e3o com monitoriza\u00e7\u00e3o proporciona o melhor desempenho a longo prazo.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-serverproblem-7193.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Porque \u00e9 que as p\u00e1ginas incorrectas do PHP-FPM Children bloqueiam<\/h2>\n\n<p>Cada pedido din\u00e2mico do WordPress requer o seu pr\u00f3prio <strong>Trabalhador<\/strong>, e s\u00e3o precisamente estes processos que a pool controla atrav\u00e9s do pm.max_children. Se eu definir um valor muito baixo, os pedidos se acumulam em uma fila e o <strong>TTFB<\/strong> aumenta visivelmente. Se eu definir o valor muito alto, cada processo filho usa RAM adicional e o servidor muda para swap. Tudo fica mais lento na swap at\u00e9 que o Apache ou o Nginx reportem 502\/504 ou o OOM killer encerre os processos. Uma taxa de transfer\u00eancia saud\u00e1vel s\u00f3 \u00e9 alcan\u00e7ada quando o n\u00famero de filhos corresponde ao or\u00e7amento real de RAM e \u00e0 carga do projeto.<\/p>\n\n<h2>A f\u00f3rmula para pm.max_children na pr\u00e1tica<\/h2>\n\n<p>Come\u00e7o com a f\u00f3rmula simples: a RAM dispon\u00edvel para o PHP dividida pelo tamanho m\u00e9dio de um processo filho, multiplicado por um <strong>Fator de seguran\u00e7a<\/strong> Determino a RAM por processo com ps e a coluna RSS; para pilhas t\u00edpicas de WordPress, 50-250 MB \u00e9 frequentemente correto. Num servidor de 4 GB, reservo mem\u00f3ria para o Linux, base de dados e servi\u00e7os de cache, deixando cerca de 1,5-2 GB para <strong>PHP<\/strong> permanecem. Por exemplo, se a m\u00e9dia do processo for de 100 MB, 2.000 \/ 100 \u00d7 0,75 = 15 crian\u00e7as. Este valor serve como ponto de partida, que eu refino de acordo com o perfil de carga, cache e combina\u00e7\u00e3o de plugins.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_fpm_meeting_4287.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Valores iniciais para configura\u00e7\u00f5es t\u00edpicas do WordPress<\/h2>\n\n<p>Para blogues pequenos com 2 GB de RAM, 8 crian\u00e7as, pm = din\u00e2mico e um pm.max_requests de aprox. <strong>800<\/strong>. Para projectos de m\u00e9dia dimens\u00e3o com 4 GB de RAM, defino 12 filhos, start_servers 4, min_spare_servers 4. As grandes lojas com 8 GB de RAM ou mais beneficiam de 21-40 filhos; se a carga for permanentemente elevada, pm = static pode assegurar um d\u00e9bito constante. Em seguida, verifico o r\u00e1cio de utiliza\u00e7\u00e3o da CPU, a utiliza\u00e7\u00e3o da RAM e os tempos de resposta para fazer ajustes finos. Se quiser aprofundar o assunto, pode encontrar informa\u00e7\u00e3o de base em <a href=\"https:\/\/webhosting.de\/pt\/wordpress-php-fpm-definicoes-optimas-desempenho-serverboost\/\">defini\u00e7\u00f5es PHP-FPM optimizadas<\/a>.<\/p>\n\n<h2>Medi\u00e7\u00e3o de processos: como determinar os requisitos de RAM<\/h2>\n\n<p>Primeiro determino a dimens\u00e3o real dos processos antes de definir valores, porque as bolas de cristal n\u00e3o ajudam aqui e custam dinheiro. <strong>Desempenho<\/strong>. O comando ps -ylC php-fpm -sort:rss retorna os tamanhos dos RSS, que eu monitorizo durante alguns minutos. Os processos crescem frequentemente durante actualiza\u00e7\u00f5es ou tarefas cron, raz\u00e3o pela qual incluo picos no c\u00e1lculo. Eu tamb\u00e9m uso htop e free -h para verificar as reservas de RAM e a quantidade de swap. Utilizo estes dados para determinar uma m\u00e9dia fi\u00e1vel e selecciono um fator de seguran\u00e7a conservador.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-phpfpm-blockiert-9327.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Par\u00e2metros importantes num relance<\/h2>\n\n<p>Para al\u00e9m do pm.max_children, outras op\u00e7\u00f5es de pool determinam a forma como o WordPress processa os pedidos de forma limpa e a forma como liberta mem\u00f3ria, o que reduz visivelmente o <strong>Estabilidade<\/strong> pm regula o modo: dynamic ajusta o n\u00famero de processos \u00e0 carga, static mant\u00e9m um n\u00famero fixo. pm.max_requests previne o incha\u00e7o da mem\u00f3ria reiniciando os processos ap\u00f3s X pedidos. request_terminate_timeout protege contra os bloqueios causados por scripts defeituosos ou lentos. Com este conjunto, eu cubro 90 por cento dos casos pr\u00e1ticos reais.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metros<\/th>\n      <th>Fun\u00e7\u00e3o<\/th>\n      <th>Recomenda\u00e7\u00e3o do WordPress<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>pm<\/td>\n      <td>Modo de controlo do processo<\/td>\n      <td>din\u00e2mico para carga vari\u00e1vel; est\u00e1tico para tr\u00e1fego permanentemente elevado<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_children<\/td>\n      <td>N\u00famero m\u00e1ximo de trabalhadores em simult\u00e2neo<\/td>\n      <td>RAM PHP dispon\u00edvel \/ tamanho do processo \u00d7 0,75<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_requests<\/td>\n      <td>Reciclagem de processos<\/td>\n      <td>300-1.000; um pouco menos com WooCommerce<\/td>\n    <\/tr>\n    <tr>\n      <td>request_terminate_timeout<\/td>\n      <td>Cancelamento de pedidos de longa dura\u00e7\u00e3o<\/td>\n      <td>60-120 segundos contra cabides<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Din\u00e2mico, a pedido ou est\u00e1tico - qual o modo mais adequado para si?<\/h2>\n<p>Selecciono o modo de acordo com o perfil de carga: <strong>din\u00e2mico<\/strong> \u00e9 a minha predefini\u00e7\u00e3o, porque ajusta de forma flex\u00edvel o n\u00famero de processos activos e, assim, poupa RAM quando h\u00e1 pouca coisa a acontecer. <strong>est\u00e1tico<\/strong> Utilizo-a quando a carga \u00e9 constante e preciso de compromissos rigorosos em termos de lat\u00eancia e d\u00e9bito - por exemplo, durante campanhas ou vendas. <strong>a pedido<\/strong> \u00e9 adequado para servidores com longas fases de inatividade: Os processos s\u00e3o criados apenas quando necess\u00e1rio e terminados novamente ap\u00f3s inatividade. A desvantagem \u00e9 o arranque a frio; o primeiro pedido por novo processo parece mais lento. Para ondemand, defini <em>pm.process_idle_timeout<\/em> de forma limpa (por exemplo, 10-20s), com din\u00e2mica mantenho <em>iniciar_servidores<\/em>, <em>servidores de reserva m\u00ednimos<\/em> e <em>m\u00e1ximo de servidores de reserva<\/em> apertado para que a piscina escale rapidamente mas n\u00e3o \u201eencha\u201c.<\/p>\n\n<h2>Exemplo de configura\u00e7\u00e3o para a sua piscina<\/h2>\n\n<p>Na Debian\/Ubuntu, o ficheiro de pool est\u00e1 normalmente localizado em \/etc\/php\/8.x\/fpm\/pool.d\/www.conf, o que me d\u00e1 uma clara <strong>Estrutura<\/strong> para personaliza\u00e7\u00f5es. Defino pm como din\u00e2mico, ancoro um valor realista para pm.max_children e mantenho o servidor de reserva apertado. Defino a reciclagem para 500, a fim de limitar as fugas e os aumentos de RAM numa fase inicial. Depois de cada altera\u00e7\u00e3o, testo a carga e elimino os estrangulamentos antes de aumentar ainda mais os valores. Para obter informa\u00e7\u00f5es b\u00e1sicas sobre os valores limite, a vis\u00e3o em <a href=\"https:\/\/webhosting.de\/pt\/php-fpm-gestao-de-processos-pm-max-children-otimizar-nucleo\/\">Otimizar pm.max_children<\/a>.<\/p>\n\n<pre><code>pm = din\u00e2mico\npm.max_children = 15\npm.start_servers = 4\npm.min_spare_servers = 4\npm.max_spare_servers = 8\npm.max_requests = 500\nrequest_terminate_timeout = 90s\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_phpfpm_techoffice_9271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Piscinas m\u00faltiplas, tomadas e isolamento limpo<\/h2>\n<p>Para v\u00e1rios projectos ou fun\u00e7\u00f5es claramente separadas (frontend vs. admin\/REST), configuro <strong>piscinas separadas<\/strong> com o seu pr\u00f3prio utilizador e socket. Desta forma, cada pool limita os seus pr\u00f3prios filhos e um outlier n\u00e3o bloqueia os restantes. Em um host, eu prefiro <strong>Soquetes Unix<\/strong> comparado ao TCP (listen = \/run\/php\/site.sock) - menor lat\u00eancia, menos sobrecarga. Eu uso TCP entre Nginx\/Apache e PHP-FPM em diferentes hosts\/cont\u00eaineres. Eu uso <em>propriet\u00e1rio da lista<\/em>, <em>listen.group<\/em> e <em>modo de escuta<\/em> coerente e, se necess\u00e1rio, aumentar <em>lista.backlog<\/em> para que pequenos picos de carga n\u00e3o resultem em erros de liga\u00e7\u00e3o. Com um pool de administradores dedicados, posso conseguir uma <em>request_terminate_timeout<\/em> conduzir e <em>pm.max_requests<\/em> mais baixo sem abrandar o pool de front-end com cache forte.<\/p>\n\n<h2>Reconhecer os sintomas e reagir corretamente<\/h2>\n\n<p>Se o registo de erros indicar regularmente \u201eserver reached pm.max_children\u201c, o pool est\u00e1 a limitar o <strong>Paralelismo<\/strong> e aumento-o moderadamente. Se ocorrerem 502\/504 com alta utiliza\u00e7\u00e3o de swap ao mesmo tempo, eu redefino pm.max_children e diminuo pm.max_requests. Se a CPU aumenta com baixa utiliza\u00e7\u00e3o de RAM, ent\u00e3o as consultas ou a l\u00f3gica PHP est\u00e3o normalmente a bloquear; optimizo a base de dados e o caching. Se os pedidos ficarem bloqueados, um request_terminate_timeout mais rigoroso e uma an\u00e1lise do registo com marcas temporais ajudam. Verifico picos consp\u00edcuos em rela\u00e7\u00e3o a cronjobs, \u00edndices de pesquisa e ac\u00e7\u00f5es administrativas.<\/p>\n\n<h2>Estado do FPM e slowlog: diagn\u00f3stico preciso<\/h2>\n<p>Eu ativo o <strong>Estado<\/strong> por pool (pm.status_path) e ler \u00edndices como <em>processos activos<\/em>, <em>m\u00e1ximo de crian\u00e7as alcan\u00e7adas<\/em>, <em>fila de escuta<\/em> e <em>fila de escuta m\u00e1xima<\/em> desligado. Uma fila de listas em permanente crescimento mostra claramente: muito poucos filhos ou backends bloqueados. Eu tamb\u00e9m defini <em>request_slowlog_timeout<\/em> (por exemplo, 3-5s) e um <em>registo lento<\/em>-path. \u00c9 assim que vejo os tra\u00e7os de pilha dos pedidos que est\u00e3o a demorar - frequentemente chamadas HTTP externas, consultas complexas do WooCommerce ou manipula\u00e7\u00f5es de imagens. Com <em>capturar_sa\u00edda_dos_trabalhadores<\/em> os avisos dos trabalhadores s\u00e3o recolhidos nos registos. Com base nestes dados, decido se mais paralelismo ajuda ou se preciso de resolver os estrangulamentos no c\u00f3digo\/DB.<\/p>\n\n<h2>Controlo: 3-5 dias de avalia\u00e7\u00e3o limpa<\/h2>\n\n<p>Ap\u00f3s a afina\u00e7\u00e3o, monitorizo os picos de carga durante v\u00e1rios dias, porque a curto prazo <strong>flutua\u00e7\u00f5es<\/strong> enganar. Registo a RAM, swap, 502\/504, TTFB e o n\u00famero de processos activos no estado FPM. Abaixo de 80% de utiliza\u00e7\u00e3o de RAM sem swap e sem filas, estou correto. Se ocorrerem estrangulamentos durante ac\u00e7\u00f5es como o checkout, a pesquisa ou as importa\u00e7\u00f5es, ajusto especificamente pm.max_children e pm.max_requests. Cada passo \u00e9 efectuado em pequenos ajustes e com uma nova medi\u00e7\u00e3o.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_phpfpm_bugfix_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00e1lculo da mem\u00f3ria em pormenor: RSS, PSS e mem\u00f3ria partilhada<\/h2>\n<p>A vari\u00e1vel de processo \u00e9 complicada: <strong>RSS<\/strong> (Resident Set Size) tamb\u00e9m cont\u00e9m segmentos partilhados, como a OPcache e as bibliotecas. Por conseguinte, sobrestimo rapidamente o consumo de RAM se me limitar a calcular \u201eRSS \u00d7 Children\u201c. \u00c9 melhor usar o <strong>PSS<\/strong>-view (Proportional Set Size), que distribui a mem\u00f3ria partilhada de forma justa pelos processos - ferramentas como o smem ajudam aqui. O c\u00e1lculo inclui <strong>OPcache<\/strong> (por exemplo, 256 MB + cadeias de caracteres), <strong>APCu<\/strong> (por exemplo, 64-128 MB) e o processo mestre. O PHP <em>memory_limit<\/em> n\u00e3o \u00e9 uma m\u00e9dia, mas o limite superior por pedido; podem ocorrer picos individuais, mas o valor m\u00e9dio conta. Planeio uma reserva para que os picos, as implementa\u00e7\u00f5es e os cronjobs n\u00e3o desencadeiem imediatamente as trocas e deixo <em>pm.max_requests<\/em> para limitar o aumento da mem\u00f3ria.<\/p>\n\n<h2>Reduzir a carga espec\u00edfica do WordPress<\/h2>\n\n<p>Reduzo primeiro a carga do PHP, antes de aumentar ainda mais as crian\u00e7as, porque uma taxa de acerto da cache mais r\u00e1pida poupa tempo real. <strong>RAM<\/strong>. As caches de p\u00e1gina inteira reduzem drasticamente os pedidos de PHP, o que cria capacidade para checkout, pesquisa e administra\u00e7\u00e3o. OPcache com memory_consumption de 256 MB acelera o bytecode e alivia o pool. Na pr\u00e1tica, mantenho o memory_limit do PHP em 256M para que os plugins individuais n\u00e3o tornem o servidor mais lento. Mais informa\u00e7\u00f5es sobre gargalos podem ser encontradas no guia <a href=\"https:\/\/webhosting.de\/pt\/php-workers-hosting-bottleneck-guide-balance\/\">PHP Worker como gargalo<\/a>.<\/p>\n\n<h2>Backends da base de dados e da cache em equil\u00edbrio<\/h2>\n<p>Todo PHP worker potencialmente gera um <strong>Liga\u00e7\u00e3o \u00e0 base de dados<\/strong>. Se eu aumentar o pm.max_children, a carga simult\u00e2nea da BD tamb\u00e9m aumenta. Por conseguinte, verifico o MySQL\/MariaDB: <em>max_conex\u00f5es<\/em>, buffer (innodb_buffer_pool_size), e o planeador de consultas. O Redis\/Memcached deve manter-se em paralelo - <em>clientes m\u00e1ximos<\/em>, limite de mem\u00f3ria e lat\u00eancias. Uma inst\u00e2ncia do WordPress com 20 filhos activos pode facilmente saturar a BD se v\u00e1rias consultas dispendiosas estiverem a ser executadas em paralelo. \u00c9 por isso que eu ajusto o banco de dados (\u00edndices, consultas lentas) e defino como <strong>Caches de objectos persistentes<\/strong>, antes de libertar mais crian\u00e7as. Isto aumenta o rendimento sem sobrecarregar o backend.<\/p>\n\n<h2>WooCommerce, Cron e Admin: casos especiais<\/h2>\n\n<p>As lojas geram mais pedidos din\u00e2micos simult\u00e2neos, e \u00e9 por isso que utilizo algo <strong>Ar<\/strong> com pm.max_children. Ao mesmo tempo, tendo a diminuir o pm.max_requests para reduzir continuamente o incha\u00e7o da mem\u00f3ria. Para importa\u00e7\u00f5es e cronjobs, eu planeio um or\u00e7amento adicional ou executo tarefas fora das horas de pico. A \u00e1rea de administra\u00e7\u00e3o frequentemente tem picos de acessos a curto prazo; o caching fornece menos prote\u00e7\u00e3o aqui, ent\u00e3o um controle eficiente do pool conta. Se houver sinais de filas de espera, aumento em pequenos passos e monitorizo as m\u00e9tricas imediatamente a seguir.<\/p>\n\n<h2>Contentores, quotas de vCPU e armadilhas OOM<\/h2>\n<p>Em contentores e VMs, o foco est\u00e1 no <strong>efetivo<\/strong> limite de RAM (cgroups), n\u00e3o no host. Portanto, eu calculo pm.max_children a partir do limite alocado e n\u00e3o a partir de \u201efree -h\u201c. OOMs de cont\u00eaineres s\u00e3o impiedosos - o kernel termina os processos com for\u00e7a. As quotas de CPU tamb\u00e9m contam: Mais filhos n\u00e3o ajudam se 1-2 vCPUs limitam o tempo de computa\u00e7\u00e3o. Como regra geral, eu dimensiono as cargas de trabalho do WordPress com IO pesado para cerca de 2-4\u00d7 o n\u00famero de vCPUs; acima disso, as trocas de contexto aumentam, mas n\u00e3o a taxa de transfer\u00eancia real. Em ambientes orquestrados, fa\u00e7o altera\u00e7\u00f5es de forma conservadora, observo reinicializa\u00e7\u00f5es de pods e mantenho sondas de prontid\u00e3o\/vida para que as fases curtas de aquecimento do FPM n\u00e3o sejam contadas como falhas.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-server-techniker-7483.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fontes de erro que s\u00e3o frequentemente ignoradas<\/h2>\n\n<p>Muitos problemas n\u00e3o t\u00eam origem na piscina, mas sim <strong>Plugins<\/strong>, que multiplicam os pedidos ou geram processos longos. As pesquisas indexadas, as regras de rastreio quebradas e os intervalos excessivos de batimentos card\u00edacos aumentam a carga. Por isso, verifico sempre primeiro os registos, o monitor de consultas e os cabe\u00e7alhos de cache. Se a carga ocorrer apenas com determinados URLs, interpreto isso como uma indica\u00e7\u00e3o de estrangulamentos de plugins ou modelos. S\u00f3 quando estes problemas tiverem sido resolvidos \u00e9 que eu aumento a escala das crian\u00e7as.<\/p>\n\n<h2>Compreender as sess\u00f5es, o AJAX administrativo e os bloqueios<\/h2>\n<p>WordPress\/plugins funcionam parcialmente com <strong>Sess\u00f5es<\/strong>. Os bloqueios de sess\u00e3o baseados em ficheiros podem serializar pedidos - um \u00fanico pedido lento bloqueia os restantes pedidos com o mesmo ID de sess\u00e3o. Mantenho a utiliza\u00e7\u00e3o da sess\u00e3o reduzida e verifico se as explos\u00f5es de AJAX do administrador (wp-admin\/admin-ajax.php) s\u00e3o desnecessariamente frequentes. O batimento card\u00edaco deve ser acelerado de forma sensata, caso contr\u00e1rio gera carga sem valor acrescentado. Se ocorrerem bloqueios ou longos acessos a ficheiros, um maior paralelismo n\u00e3o ajudar\u00e1; o caching, uma E\/S de armazenamento mais r\u00e1pida ou um manipulador de sess\u00e3o diferente ajudar\u00e3o aqui. Nos registos, reconhe\u00e7o esses padr\u00f5es a partir de muitos pedidos semelhantes que come\u00e7am ao mesmo tempo com tempos de execu\u00e7\u00e3o invulgarmente longos.<\/p>\n\n<h2>Vis\u00e3o geral dos tempos limite do Nginx, Apache e FastCGI<\/h2>\n\n<p>O servidor Web tamb\u00e9m estabelece limites que tenho de harmonizar com os valores do FPM, caso contr\u00e1rio, eles desaparecem. <strong>Afina\u00e7\u00e3o<\/strong>. Com o Nginx, presto aten\u00e7\u00e3o ao fastcgi_read_timeout e a processos de trabalho suficientes. No Apache, verifico mpm_event, defini\u00e7\u00f5es keepalive e timeouts de proxy. Se estes limites n\u00e3o estiverem corretos, os utilizadores reportam timeouts, apesar de o FPM ainda ter capacidade. Os or\u00e7amentos de tempo normalizados mant\u00eam o caminho do cliente para o PHP consistente.<\/p>\n\n<h2>Estrat\u00e9gia de implanta\u00e7\u00e3o, testes e funcionamento<\/h2>\n<p>Fa\u00e7o altera\u00e7\u00f5es ao pm.max_children passo a passo e testo-as sob carga real. Uma recarga do FPM (graceful) assume as configura\u00e7\u00f5es sem quebrar a conex\u00e3o. Antes de saltos maiores, eu simulo picos (por exemplo, in\u00edcio de venda) e observo <em>fila de escuta<\/em>, CPU, RAM, 95\u00ba-99\u00ba percentil de lat\u00eancia e taxas de erro. Documentei as suposi\u00e7\u00f5es feitas para que os membros posteriores da equipa compreendam porque \u00e9 que um valor foi escolhido desta forma. Defino alarmes para: swap &gt; 0, \u201emax children reached\u201c no estado, aumento de 502\/504 e lat\u00eancia da BD. Isso garante que a plataforma permane\u00e7a est\u00e1vel mesmo meses depois, quando o tr\u00e1fego e a combina\u00e7\u00e3o de plug-ins mudam.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Defini\u00e7\u00e3o incorrecta <strong>PHP-FPM<\/strong>-Os filhos atrasam o WordPress, seja nas filas ou no limite de RAM. Determino o tamanho do processo, reservo mem\u00f3ria para os servi\u00e7os do sistema e defino pm.max_children com buffer. Em seguida, verifico pm.max_requests, request_terminate_timeout e o modo pm = din\u00e2mico ou est\u00e1tico de acordo com o perfil de carga. Caching, OPcache e plugins limpos reduzem visivelmente o n\u00famero de pedidos de PHP. Se implementar estes passos de forma consistente, manter\u00e1 as p\u00e1ginas responsivas e o servidor fi\u00e1vel.<\/p>","protected":false},"excerpt":{"rendered":"<p>Os **PHP-FPM Children** incorrectos bloqueiam os sites WordPress. Aprenda o ajuste do php-fpm wordpress para obter o desempenho perfeito do wp php children e da hospedagem.<\/p>","protected":false},"author":1,"featured_media":17351,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-17358","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1407","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"PHP-FPM Children","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"17351","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/17358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=17358"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/17358\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/17351"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=17358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=17358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=17358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}