{"id":16053,"date":"2025-12-20T11:51:36","date_gmt":"2025-12-20T10:51:36","guid":{"rendered":"https:\/\/webhosting.de\/php-fpm-prozess-management-pm-max-children-optimieren-core\/"},"modified":"2025-12-20T11:51:36","modified_gmt":"2025-12-20T10:51:36","slug":"php-fpm-gestao-de-processos-pm-max-children-otimizar-nucleo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/php-fpm-prozess-management-pm-max-children-optimieren-core\/","title":{"rendered":"Configurar corretamente a gest\u00e3o de processos PHP-FPM: pm.max_children &amp; Co. explicado"},"content":{"rendered":"<p><strong>Ajuste do php-fpm<\/strong> decide quantos processos PHP-FPM podem ser executados simultaneamente, a rapidez com que novos processos s\u00e3o iniciados e por quanto tempo eles atendem \u00e0s solicita\u00e7\u00f5es. Vou mostrar-lhe como <strong>pm.max_children<\/strong>, pm, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers e pm.max_requests de forma a que a sua aplica\u00e7\u00e3o responda rapidamente sob carga e o servidor n\u00e3o entre em swapping.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>modo pm<\/strong>: escolha corretamente entre est\u00e1tico, din\u00e2mico ou sob demanda, para que os processos estejam dispon\u00edveis de acordo com o seu tr\u00e1fego.<\/li>\n  <li><strong>pm.max_children<\/strong>: Alinhar o n\u00famero de processos PHP simult\u00e2neos na RAM com o consumo real do processo.<\/li>\n  <li><strong>Valores iniciais\/de reserva<\/strong>: equilibrar adequadamente pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.<\/li>\n  <li><strong>Reciclagem<\/strong>: Amortecer fugas de mem\u00f3ria com pm.max_requests, sem criar sobrecarga desnecess\u00e1ria.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong>: Monitorize os registos, o estado e a RAM e, em seguida, fa\u00e7a ajustes graduais.<\/li>\n<\/ul>\n\n<h2>Por que a gest\u00e3o de processos \u00e9 importante<\/h2>\n\n<p>Eu participo <strong>PHP-FPM<\/strong> a execu\u00e7\u00e3o de cada script PHP como um processo separado, e cada solicita\u00e7\u00e3o paralela precisa do seu pr\u00f3prio trabalhador. Sem limites adequados, as solicita\u00e7\u00f5es ficam bloqueadas em filas, o que leva a <strong>Intervalos<\/strong> e erros. Se eu definir limites m\u00e1ximos muito altos, o pool de processos consome a mem\u00f3ria e o kernel come\u00e7a a <strong>trocar<\/strong>. Esse equil\u00edbrio n\u00e3o \u00e9 uma quest\u00e3o de adivinha\u00e7\u00e3o: eu me baseio em valores reais e mantenho uma margem de seguran\u00e7a. Assim, a lat\u00eancia permanece baixa e a taxa de transfer\u00eancia est\u00e1vel, mesmo quando a carga oscila.<\/p>\n\n<p>Para mim, \u00e9 importante ter uma <strong>valor-alvo<\/strong>: Quantas execu\u00e7\u00f5es PHP simult\u00e2neas pretendo permitir sem esgotar a RAM? Ao mesmo tempo, verifico se os gargalos ocorrem mais na <strong>Base de dados<\/strong>, em APIs externas ou no servidor web. S\u00f3 quando conhe\u00e7o o gargalo \u00e9 que escolho os valores corretos para pm, pm.max_children e outros. Come\u00e7o de forma conservadora, avalio e depois aumento gradualmente. Assim evito reinicializa\u00e7\u00f5es bruscas e falhas inesperadas.<\/p>\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\/2025\/12\/php-fpm-serveradmin-4912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Os tr\u00eas modos pm: static, dynamic, ondemand<\/h2>\n\n<p>O modo <strong>est\u00e1tico<\/strong> mant\u00e9m sempre exatamente pm.max_children processos dispon\u00edveis. Isso proporciona lat\u00eancias muito previs\u00edveis, pois n\u00e3o \u00e9 necess\u00e1rio nenhum processo de inicializa\u00e7\u00e3o. Eu uso static quando a carga \u00e9 muito uniforme e h\u00e1 RAM suficiente dispon\u00edvel. No entanto, quando a demanda varia, eu desperdi\u00e7o facilmente em static. <strong>Mem\u00f3ria<\/strong>. Por isso, utilizo static especificamente onde preciso de uma execu\u00e7\u00e3o constante.<\/p>\n\n<p>Com <strong>din\u00e2mico<\/strong> Eu inicio uma quantidade inicial e deixo o tamanho do pool oscilar entre min_spare e max_spare. Este modo \u00e9 adequado para tr\u00e1fego com picos, porque os trabalhadores s\u00e3o criados e encerrados conforme necess\u00e1rio. Eu mantenho sempre processos ociosos suficientes para lidar com picos sem tempo de espera. No entanto, muitos trabalhadores ociosos ocupam recursos desnecessariamente. <strong>RAM<\/strong>, por isso mantenho a margem de poupan\u00e7a reduzida. Assim, a piscina permanece flex\u00edvel, sem inchar.<\/p>\n\n<p>No modo <strong>a pedido<\/strong> Inicialmente, n\u00e3o existem trabalhadores, o PHP-FPM s\u00f3 os inicia quando h\u00e1 solicita\u00e7\u00f5es. Isso economiza mem\u00f3ria em per\u00edodos de inatividade, mas o primeiro acesso tem um pouco de lat\u00eancia. Eu escolho ondemand para pools raramente acessados, ferramentas administrativas ou pontos finais cron. Para sites muito frequentados, ondemand geralmente oferece tempos de resposta piores. Nesses casos, eu prefiro claramente dynamic com valores de reserva bem definidos.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm_konfiguration_9542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionar corretamente o pm.max_children<\/h2>\n\n<p>Penso que sim <strong>pm.max_children<\/strong> da RAM dispon\u00edvel para PHP e da mem\u00f3ria m\u00e9dia por trabalhador. Para isso, primeiro reservo mem\u00f3ria para o sistema, servidor web, base de dados e caches, para que o sistema n\u00e3o entre em <strong>Externaliza\u00e7\u00e3o<\/strong> funciona. Divido a RAM restante pelo consumo real medido do processo. Da teoria, retiro uma margem de seguran\u00e7a de 20\u201330 % para compensar valores at\u00edpicos e picos de carga. Utilizo o resultado como valor inicial e, em seguida, observo o efeito.<\/p>\n\n<p>Eu determino o consumo m\u00e9dio do processo com ferramentas como <strong>ps<\/strong>, top ou htop e vejo RSS\/RES. Importante: eu fa\u00e7o a medi\u00e7\u00e3o sob carga t\u00edpica, n\u00e3o em modo inativo. Quando carrego muitos plugins, frameworks ou bibliotecas grandes, o consumo por trabalhador aumenta significativamente. Al\u00e9m disso, a CPU limita a curva: mais processos n\u00e3o ajudam quando um <strong>Rosca simples<\/strong>-Desempenho da CPU limitado por solicita\u00e7\u00e3o. Quem quiser aprofundar-se nas caracter\u00edsticas da CPU encontrar\u00e1 informa\u00e7\u00f5es sobre <a href=\"https:\/\/webhosting.de\/pt\/php-single-thread-performance-wordpress-hosting-velocity\/\">Desempenho de thread \u00fanico<\/a>.<\/p>\n\n<p>Mantenho as minhas suposi\u00e7\u00f5es transparentes: quanta RAM est\u00e1 realmente dispon\u00edvel para o PHP? Qual \u00e9 o tamanho de um trabalhador em pedidos t\u00edpicos? Quais s\u00e3o os picos que ocorrem? Se as respostas estiverem corretas, defino pm.max_children, fa\u00e7o uma recarga suave e controlo a RAM, os tempos de resposta e as taxas de erro. S\u00f3 depois disso \u00e9 que continuo a subir ou descer em pequenos passos.<\/p>\n\n<h2>Valores de refer\u00eancia de acordo com o tamanho do servidor<\/h2>\n\n<p>A tabela seguinte fornece-me <strong>Valores iniciais<\/strong> \u00e0 m\u00e3o. N\u00e3o substitui a medi\u00e7\u00e3o, mas fornece uma orienta\u00e7\u00e3o s\u00f3lida para as primeiras configura\u00e7\u00f5es. Eu ajusto os valores para cada aplica\u00e7\u00e3o e verifico-os com monitoriza\u00e7\u00e3o. Se as reservas permanecerem inutilizadas, eu aumento cuidadosamente. Se o servidor atingir o limite da RAM, eu reduzo os valores.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>RAM do servidor<\/strong><\/th>\n      <th><strong>RAM para PHP<\/strong><\/th>\n      <th><strong>\u00d8 MB\/Trabalhador<\/strong><\/th>\n      <th><strong>pm.max_children<\/strong> (In\u00edcio)<\/th>\n      <th><strong>Utiliza\u00e7\u00e3o<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>1\u20132 GB<\/td>\n      <td>~1 GB<\/td>\n      <td>50\u201360<\/td>\n      <td>15\u201320<\/td>\n      <td>Pequenos sites, blogs<\/td>\n    <\/tr>\n    <tr>\n      <td>4\u20138 GB<\/td>\n      <td>~4\u20136 GB<\/td>\n      <td>60\u201380<\/td>\n      <td>30\u201380<\/td>\n      <td>Neg\u00f3cios, pequenas lojas<\/td>\n    <\/tr>\n    <tr>\n      <td>16+ GB<\/td>\n      <td>~10\u201312 GB<\/td>\n      <td>70\u201390<\/td>\n      <td>100\u2013160<\/td>\n      <td>Alta carga, API, lojas<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Eu leio a tabela da direita para a esquerda: O <strong>Utiliza\u00e7\u00e3o<\/strong> Para o projeto, verifico se a RAM est\u00e1 reservada de forma realista para o PHP. Em seguida, seleciono um tamanho de worker adequado \u00e0 base de c\u00f3digo e \u00e0s extens\u00f5es. Depois, defino o pm.max_children e observo o efeito em tempo real. A taxa de acerto e a estabilidade aumentam quando documento estas etapas de forma clara.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/php-fpm-prozessmanagement-5124.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Definir valores iniciais, de reserva e de pedidos<\/h2>\n\n<p>Com <strong>pm.iniciar_servidores<\/strong> Eu defino quantos processos est\u00e3o imediatamente dispon\u00edveis. Um n\u00famero muito baixo gera arranques a frio sob carga, um n\u00famero muito alto ocupa RAM desnecessariamente. Costumo usar 15\u201330 % de pm.max_children e arredondo quando a carga come\u00e7a mais calma. Em picos de tr\u00e1fego, escolho uma quantidade inicial um pouco maior para que as solicita\u00e7\u00f5es n\u00e3o cheguem antes que haja trabalhadores suficientes \u00e0 espera. Esse ajuste fino reduz significativamente o tempo de resposta inicial.<\/p>\n\n<p>Os valores <strong>pm.min_servidores_sobressalentes<\/strong> e pm.max_spare_servers definem o intervalo de inatividade. Eu mantenho tantos trabalhadores livres que novas solicita\u00e7\u00f5es tenham acesso direto, mas n\u00e3o tantos a ponto de os processos ociosos desperdi\u00e7arem mem\u00f3ria. Para lojas, gosto de definir uma janela mais restrita para suavizar picos. Com <strong>pm.max_requests<\/strong> Eu reciclo processos ap\u00f3s algumas centenas de solicita\u00e7\u00f5es para limitar o desvio de mem\u00f3ria. Para aplica\u00e7\u00f5es discretas, eu escolho 500\u2013800, mas se houver suspeita de vazamentos, eu deliberadamente escolho um n\u00famero menor.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e resolu\u00e7\u00e3o de problemas<\/h2>\n\n<p>Verifico regularmente <strong>Registos<\/strong>, p\u00e1ginas de estado e RAM. Avisos sobre limites pm.max_children atingidos s\u00e3o para mim um sinal claro para aumentar o limite m\u00e1ximo ou otimizar o c\u00f3digo\/banco de dados. Se os erros 502\/504 se acumulam, eu verifico os registos do servidor web e as filas. Flutua\u00e7\u00f5es significativas na lat\u00eancia indicam poucos processos, I\/O bloqueado ou custos de processo demasiado elevados. Primeiro, analiso os factos concretos e, em seguida, reajo com pequenos passos, nunca com saltos XXL.<\/p>\n\n<p>Consigo identificar os pontos cr\u00edticos mais rapidamente quando utilizo o <strong>Tempos de espera<\/strong> Ao longo de toda a cadeia: servidor web, PHP-FPM, base de dados, servi\u00e7os externos. Se o tempo de backend aumentar apenas em determinadas rotas, isolo as causas atrav\u00e9s de profiling. Se os tempos de espera ocorrerem em todos os locais, intervenho no tamanho do servidor e do pool. Tamb\u00e9m \u00e9 \u00fatil dar uma olhada nas filas de trabalho e nos processos no status D. S\u00f3 quando eu entendo a situa\u00e7\u00e3o \u00e9 que altero os limites \u2013 e documento cada altera\u00e7\u00e3o de forma clara.<\/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\/2025\/12\/phpfpm_nachtarbeit_tech5982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Servidor web e PHP-FPM em intera\u00e7\u00e3o<\/h2>\n\n<p>Certifico-me de que <strong>Servidor Web<\/strong>-Limites e PHP-FPM harmonizam-se. Demasiadas liga\u00e7\u00f5es simult\u00e2neas no servidor web com poucos trabalhadores causam filas de espera e tempos de espera. Se os trabalhadores forem aumentados, mas o servidor web limitar a aceita\u00e7\u00e3o, o desempenho fica aqu\u00e9m. Par\u00e2metros como worker_connections, event-Loop e Keep-Alive afetam diretamente a carga do PHP. Uma introdu\u00e7\u00e3o pr\u00e1tica ao ajuste fino \u00e9 fornecida por dicas sobre <a href=\"https:\/\/webhosting.de\/pt\/threadpool-servidor-web-apache-nginx-litespeed-otimizacao-configuracao\/\">Threadpools no servidor web<\/a>.<\/p>\n\n<p>Eu fico com <strong>Manter em perman\u00eancia<\/strong>-Janela de tempo em vista, para que as liga\u00e7\u00f5es ociosas n\u00e3o bloqueiem desnecessariamente os trabalhadores. Para ativos est\u00e1ticos, defino um cache agressivo antes do PHP, para manter a carga de trabalho longe do pool. Os caches de proxy reverso ajudam adicionalmente quando respostas id\u00eanticas s\u00e3o frequentemente solicitadas. Assim, posso manter o pm.max_children mais baixo e ainda assim entregar mais rapidamente. Menos trabalho por solicita\u00e7\u00e3o \u00e9 frequentemente o ajuste mais eficaz.<\/p>\n\n<h2>Parafusos de ajuste finos em php-fpm.conf<\/h2>\n\n<p>Vou al\u00e9m dos valores fundamentais e ajusto os <strong>Par\u00e2metros da piscina<\/strong> \u00d3timo. Com <strong>pm.max_spawn_rate<\/strong> limito a velocidade com que novos trabalhadores podem ser criados, para que o servidor n\u00e3o inicie processos de forma demasiado agressiva durante picos de carga e entre em CPU thrashing. Para ondemand, defino com <strong>pm.process_idle_timeout<\/strong> \u00e9 importante determinar a rapidez com que os trabalhadores n\u00e3o utilizados desaparecem \u2013 se for muito curto, gera sobrecarga inicial; se for muito longo, ocupa RAM. No caso do <strong>ouvir<\/strong>-Socket, decido entre Unix-Socket e TCP. Um Unix-Socket economiza sobrecarga e oferece uma atribui\u00e7\u00e3o de direitos clara atrav\u00e9s de <em>propriet\u00e1rio da lista<\/em>, <em>listen.group<\/em> e <em>modo de escuta<\/em>. Para ambas as variantes, eu defino <strong>lista.backlog<\/strong> suficientemente alto para que os bursts que chegam sejam armazenados no buffer do kernel, em vez de serem imediatamente rejeitados. Com <strong>rlimit_files<\/strong> Se necess\u00e1rio, aumento o n\u00famero de ficheiros abertos por trabalhador, o que proporciona estabilidade quando h\u00e1 muitos uploads e downloads simult\u00e2neos. E, se for necess\u00e1rio estabelecer prioridades, utilizo <strong>prioridade do processo<\/strong>, para tratar os pools menos cr\u00edticos de forma um pouco secund\u00e1ria em termos de CPU.<\/p>\n\n<h2>Slowlog e prote\u00e7\u00e3o contra travamentos<\/h2>\n\n<p>Para tornar vis\u00edveis os pedidos dif\u00edceis, ativo o <strong>Slowlog<\/strong>. Com <strong>request_slowlog_timeout<\/strong> defino o limite (por exemplo, 2\u20133 s) a partir do qual um rastreio de pilha \u00e9 enviado para o <strong>registo lento<\/strong> escrito. Assim, encontro I\/O bloqueantes, loops dispendiosos ou bloqueios inesperados. Contra bloqueios reais, utilizo <strong>request_terminate_timeout<\/strong>, que \u00e9 interrompido abruptamente quando um pedido demora demasiado tempo. Considero estes intervalos de tempo consistentes com <em>tempo_de_execu\u00e7\u00e3o_m\u00e1x<\/em> do PHP e dos tempos limite do servidor web, para que uma camada n\u00e3o seja interrompida antes da outra. Na pr\u00e1tica, come\u00e7o de forma conservadora, analiso os slowlogs sob carga e ajusto os limites gradualmente at\u00e9 que os sinais sejam significativos, sem sobrecarregar o log.<\/p>\n\n<h2>Opcache, memory_limit e a sua influ\u00eancia no tamanho dos trabalhadores<\/h2>\n\n<p>Eu recebo o <strong>Cache<\/strong> no meu planeamento de RAM. A sua \u00e1rea de mem\u00f3ria partilhada n\u00e3o \u00e9 contabilizada por trabalhador, mas \u00e9 utilizada em conjunto por todos os processos. Tamanho e fragmenta\u00e7\u00e3o (<em>opcache.memory_consumption<\/em>, <em>buffer_de_strings_internas<\/em>) influenciam significativamente o tempo de aquecimento e a taxa de acertos. Um Opcache bem dimensionado reduz a press\u00e3o sobre a CPU e a RAM por solicita\u00e7\u00e3o, pois menos c\u00f3digo \u00e9 recompilado. Ao mesmo tempo, observo que <strong>memory_limit<\/strong>: Um valor elevado protege contra a falta de mem\u00f3ria em casos isolados, mas aumenta o or\u00e7amento te\u00f3rico para o pior cen\u00e1rio por trabalhador. Por isso, planeio com a m\u00e9dia medida mais uma margem, e n\u00e3o com o memory_limit puro. Funcionalidades como pr\u00e9-carregamento ou JIT aumentam a necessidade de mem\u00f3ria \u2013 testo-as especificamente e calculo o consumo adicional na conta pm.max_children.<\/p>\n\n<h2>Separar e priorizar pools<\/h2>\n\n<p>Eu divido as aplica\u00e7\u00f5es em <strong>v\u00e1rias piscinas<\/strong> quando os perfis de carga diferem significativamente. Um pool para tr\u00e1fego front-end, outro para administra\u00e7\u00e3o\/back-end e um terceiro para cron\/uploads: assim, isolo os picos e atribuo limites diferenciados. Para pontos finais raramente frequentados, defino <em>a pedido<\/em> com um pequeno tempo limite de inatividade, para o front-end <em>din\u00e2mico<\/em> com margem de manobra reduzida. Sobre <strong>utilizador\/grupo<\/strong> e, se necess\u00e1rio,. <em>chroot<\/em> Eu garanto um isolamento limpo, enquanto os direitos de socket regulam qual processo do servidor web pode aceder. Quando s\u00e3o necess\u00e1rias prioridades, o frontend recebe mais <em>pm.max_children<\/em> e, se necess\u00e1rio, uma neutra <em>prioridade do processo<\/em>, enquanto Cron\/Reports s\u00e3o executados com um or\u00e7amento menor e prioridade mais baixa. Assim, a interface do utilizador permanece responsiva, mesmo quando tarefas pesadas est\u00e3o a ser executadas em segundo plano.<\/p>\n\n<h2>Utilizar os pontos finais de estado de forma adequada<\/h2>\n\n<p>Para o diagn\u00f3stico de tempo de execu\u00e7\u00e3o, ativo <strong>pm.status_path<\/strong> e opcionalmente <strong>ping.path<\/strong> por pool. No estado, vejo trabalhadores ativos\/inativos que <em>Fila de listas<\/em>, contadores relacionados ao rendimento e m\u00e9tricas de pedidos lentos. Uma fila de lista em constante crescimento ou trabalhadores ociosos constantemente s\u00e3o sinais de alarme para mim. Eu protejo esses pontos finais atr\u00e1s de autentica\u00e7\u00e3o e uma rede interna para que nenhum detalhe operacional seja divulgado externamente. Al\u00e9m disso, eu ativo <strong>capturar_sa\u00edda_dos_trabalhadores<\/strong>, se eu quiser recolher rapidamente stdout\/stderr dos trabalhadores \u2013 por exemplo, em caso de erros dif\u00edceis de reproduzir. Combino esses sinais com m\u00e9tricas do sistema (RAM, CPU, I\/O) para decidir se aumento pm.max_children, atualizo valores de reserva ou ajusto a aplica\u00e7\u00e3o.<\/p>\n\n<h2>Particularidades em contentores e VMs<\/h2>\n\n<p>Em <strong>Container<\/strong> e pequenas VMs, tenho em conta os limites do cgroup e o risco do OOM-Killer. Defino o pm.max_children estritamente de acordo com o <em>Limite de mem\u00f3ria do contentor<\/em> e testo picos de carga para garantir que nenhum trabalhador seja encerrado. Sem swap em contentores, a margem de seguran\u00e7a \u00e9 particularmente importante. Para quotas de CPU, escalo o n\u00famero de trabalhadores para o n\u00famero de vCPU dispon\u00edvel: se a aplica\u00e7\u00e3o estiver limitada pela CPU, mais paralelismo trar\u00e1 filas em vez de rendimento. As cargas de trabalho limitadas pela E\/S suportam mais processos, desde que o or\u00e7amento de RAM seja suficiente. Al\u00e9m disso, defino <strong>limiar_de_rein\u00edcio_de_emerg\u00eancia<\/strong> e <strong>intervalo de rein\u00edcio de emerg\u00eancia<\/strong> para o processo mestre, a fim de evitar uma espiral de falhas, caso um bug raro afete v\u00e1rios filhos em um curto espa\u00e7o de tempo. Assim, o servi\u00e7o permanece dispon\u00edvel enquanto analiso a causa.<\/p>\n\n<h2>Implementa\u00e7\u00f5es e recargas sem falhas e sem interrup\u00e7\u00f5es<\/h2>\n\n<p>Estou a planear <strong>Recargas<\/strong> de modo que as solicita\u00e7\u00f5es em andamento sejam conclu\u00eddas corretamente. Um <em>recarregamento gracioso<\/em> (por exemplo, via systemd reload) adota novas configura\u00e7\u00f5es sem encerrar conex\u00f5es abertas. Eu mantenho o caminho do soquete est\u00e1vel para que o servidor web n\u00e3o veja nenhuma interrup\u00e7\u00e3o na conex\u00e3o. Em mudan\u00e7as de vers\u00e3o que invalidam muito o Opcache, eu pr\u00e9-carrego o cache (pr\u00e9-carregamento\/solicita\u00e7\u00f5es de aquecimento) para limitar os picos de lat\u00eancia logo ap\u00f3s a implementa\u00e7\u00e3o. Testo primeiro as altera\u00e7\u00f5es maiores num conjunto menor ou numa inst\u00e2ncia Canary com configura\u00e7\u00e3o id\u00eantica, antes de implementar os valores em toda a \u00e1rea. Cada ajuste \u00e9 registado com carimbo de data\/hora e capturas de ecr\u00e3 de m\u00e9tricas no meu registo de altera\u00e7\u00f5es \u2013 isso reduz o tempo de pesquisa de erros, caso haja efeitos colaterais inesperados.<\/p>\n\n<h2>Comportamento de picos e filas de espera<\/h2>\n\n<p>Eu suavizo os picos de carga com um <strong>Design de filas de espera<\/strong> ab. Eu coloco <strong>lista.backlog<\/strong> t\u00e3o alto que o kernel pode armazenar temporariamente mais tentativas de conex\u00e3o. No lado do servidor web, limito o n\u00famero m\u00e1ximo de conex\u00f5es FastCGI simult\u00e2neas por pool de forma que elas cheguem a <em>pm.max_children<\/em> \u00e9 adequado. Assim, os picos de tr\u00e1fego acumulam-se preferencialmente no servidor web (barato) do que no PHP (caro). Eu me\u00e7o o <em>Fila de listas<\/em> no estado FPM: se aumentar regularmente, eu aumento o n\u00famero de trabalhadores, otimizo as taxas de acertos do cache ou reduzo os valores agressivos de keep-alive. O objetivo \u00e9, em picos, o <em>Tempo at\u00e9 ao primeiro byte<\/em> manter est\u00e1vel, em vez de deixar as solicita\u00e7\u00f5es ficarem presas em filas intermin\u00e1veis.<\/p>\n\n<h2>Fluxo de trabalho pr\u00e1tico para ajustes<\/h2>\n\n<p>Come\u00e7o com um <strong>Auditoria<\/strong>: Or\u00e7amento de RAM, tamanho do processo, perfis de E\/S. Em seguida, defino valores iniciais conservadores para pm.max_children e o modo pm. Depois, realizo testes de carga ou observo os picos reais. Registo todas as altera\u00e7\u00f5es, incluindo m\u00e9tricas e intervalos de tempo. Ap\u00f3s cada ajuste, verifico a RAM, a lat\u00eancia P50\/P95 e as taxas de erro \u2013 s\u00f3 ent\u00e3o passo para a pr\u00f3xima etapa.<\/p>\n\n<p>Quando chego repetidamente ao limite, n\u00e3o escalo imediatamente a situa\u00e7\u00e3o. <strong>Trabalhador<\/strong>-N\u00famero. Primeiro, otimizo consultas, taxas de acertos de cache e fun\u00e7\u00f5es dispendiosas. Desvio trabalhos com grande carga de IO para filas e encurto os caminhos de resposta. S\u00f3 quando a aplica\u00e7\u00e3o funciona de forma eficiente \u00e9 que aumento o tamanho do pool. Este processo poupa recursos e evita danos consequentes noutros locais.<\/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\/2025\/12\/phpfpm_schreibtisch_7321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cen\u00e1rios t\u00edpicos: valores exemplificativos<\/h2>\n\n<p>Num servidor virtual de 2 GB, reservo cerca de <strong>1 GB<\/strong> para PHP-FPM e defino um consumo de trabalho de cerca de 50-60 MB. Assim, come\u00e7o com pm.max_children em 15-20 e uso dynamic com uma quantidade inicial pequena. Mantenho min_spare em 2-3 e max_spare em 5-6. Defino pm.max_requests para 500, para que os processos sejam trocados regularmente. Estas configura\u00e7\u00f5es proporcionam tempos de resposta est\u00e1veis para projetos pequenos.<\/p>\n\n<p>Com 8 GB de RAM, geralmente planeio 4\u20136 GB para <strong>PHP<\/strong> e defino tamanhos de trabalho de 60\u201380 MB. Isso resulta em 30\u201380 processos filhos como \u00e1rea inicial. pm.start_servers est\u00e1 entre 15 e 20, min_spare entre 10 e 15, max_spare entre 25 e 30. Escolho pm.max_requests entre 500 e 800. Sob carga, verifico se o pico de RAM deixa margem e, em seguida, aumento cuidadosamente.<\/p>\n\n<p>Em configura\u00e7\u00f5es de alta carga com 16+ GB de RAM, reservo 10\u201312 GB para <strong>FPM<\/strong>. Com 70\u201390 MB por trabalhador, chego rapidamente a 100\u2013160 processos. Se est\u00e1tico ou din\u00e2mico faz sentido depende do tipo de carga. Para uma utiliza\u00e7\u00e3o elevada permanente, o est\u00e1tico \u00e9 mais adequado, para uma procura ondulante, o din\u00e2mico. Em ambos os casos, a monitoriza\u00e7\u00e3o consistente continua a ser obrigat\u00f3ria.<\/p>\n\n<h2>Evitar obst\u00e1culos e definir prioridades<\/h2>\n\n<p>N\u00e3o confundo o n\u00famero de <strong>Visitantes<\/strong> com o n\u00famero de scripts PHP simult\u00e2neos. Muitas visualiza\u00e7\u00f5es de p\u00e1ginas atingem caches, fornecem ficheiros est\u00e1ticos ou bloqueiam fora do PHP. Por isso, dimensiono o pm.max_children de acordo com o tempo PHP medido, e n\u00e3o com as sess\u00f5es. Se os processos forem definidos de forma demasiado parcimoniosa, vejo pedidos em espera e taxas de erro crescentes. Se os valores forem demasiado elevados, a mem\u00f3ria transita para o swap e tudo fica mais lento.<\/p>\n\n<p>Um erro comum: mais processos significam mais <strong>Velocidade<\/strong>. Na verdade, o que conta \u00e9 o equil\u00edbrio entre CPU, IO e RAM. Se a CPU atingir 100 % e a lat\u00eancia disparar, mais trabalhadores dificilmente ajudar\u00e3o. \u00c9 melhor eliminar o verdadeiro gargalo ou reduzir a carga atrav\u00e9s da cache. O guia explica por que os trabalhadores s\u00e3o frequentemente o gargalo. <a href=\"https:\/\/webhosting.de\/pt\/php-workers-hosting-bottleneck-guide-balance\/\">PHP Worker como gargalo<\/a>.<\/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\/2025\/12\/phpfpm-serverkonfig-7342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Primeiro, determino o valor real <strong>RAM<\/strong>-Consumo por trabalhador e defino pm.max_children com buffer. Em seguida, seleciono o modo pm adequado ao tipo de carga e equilibro os valores iniciais e de reserva. Com pm.max_requests, mantenho os processos atualizados, sem sobrecarga desnecess\u00e1ria. Encaminho logs, status e m\u00e9tricas para um monitoramento limpo, para que cada altera\u00e7\u00e3o permane\u00e7a mensur\u00e1vel. Assim, obtenho tempos de resposta curtos, pools est\u00e1veis e uma carga de servidor com reservas para picos.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guia completo para ajuste do php-fpm: aprenda a configurar pm.max_children e outros par\u00e2metros de processo de forma ideal para maximizar o desempenho do seu php hosting.<\/p>","protected":false},"author":1,"featured_media":16046,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-16053","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"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":"2648","_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":null,"_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 tuning","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":"16046","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16053","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=16053"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16053\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/16046"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=16053"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=16053"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=16053"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}