PHP-FPM Crianças decidem no WordPress se os pedidos correm bem ou ficam retidos na fila de espera. Vou mostrar-lhe como os pedidos incorrectos pm.max_children-Os valores bloqueiam páginas, consomem RAM e a forma como calculo valores limpos.
Pontos centrais
Antes de me aprofundar mais, vou resumir brevemente as mensagens principais:
- pm.max_children determina quantos pedidos simultâneos de PHP estão a ser executados.
- Demasiado pouco As crianças geram filas de espera, 502/504 e TTFB elevado.
- Demasiado conduz a estrangulamentos na RAM, a trocas e a mortes OOM.
- FórmulaRAM PHP disponível / tamanho do processo × 0,7-0,8.
- Iterativo A afinação com monitorização proporciona o melhor desempenho a longo prazo.
Porque é que as páginas incorrectas do PHP-FPM Children bloqueiam
Cada pedido dinâmico do WordPress requer o seu próprio Trabalhador, e são precisamente estes processos que a pool controla através do pm.max_children. Se eu definir um valor muito baixo, os pedidos se acumulam em uma fila e o TTFB 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é que o Apache ou o Nginx reportem 502/504 ou o OOM killer encerre os processos. Uma taxa de transferência saudável só é alcançada quando o número de filhos corresponde ao orçamento real de RAM e à carga do projeto.
A fórmula para pm.max_children na prática
Começo com a fórmula simples: a RAM disponível para o PHP dividida pelo tamanho médio de um processo filho, multiplicado por um Fator de segurança Determino a RAM por processo com ps e a coluna RSS; para pilhas típicas de WordPress, 50-250 MB é frequentemente correto. Num servidor de 4 GB, reservo memória para o Linux, base de dados e serviços de cache, deixando cerca de 1,5-2 GB para PHP permanecem. Por exemplo, se a média do processo for de 100 MB, 2.000 / 100 × 0,75 = 15 crianças. Este valor serve como ponto de partida, que eu refino de acordo com o perfil de carga, cache e combinação de plugins.
Valores iniciais para configurações típicas do WordPress
Para blogues pequenos com 2 GB de RAM, 8 crianças, pm = dinâmico e um pm.max_requests de aprox. 800. Para projectos de média dimensão 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ébito constante. Em seguida, verifico o rácio de utilização da CPU, a utilização da RAM e os tempos de resposta para fazer ajustes finos. Se quiser aprofundar o assunto, pode encontrar informação de base em definições PHP-FPM optimizadas.
Medição de processos: como determinar os requisitos de RAM
Primeiro determino a dimensão real dos processos antes de definir valores, porque as bolas de cristal não ajudam aqui e custam dinheiro. Desempenho. 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ções ou tarefas cron, razão pela qual incluo picos no cálculo. Eu também uso htop e free -h para verificar as reservas de RAM e a quantidade de swap. Utilizo estes dados para determinar uma média fiável e selecciono um fator de segurança conservador.
Parâmetros importantes num relance
Para além do pm.max_children, outras opções de pool determinam a forma como o WordPress processa os pedidos de forma limpa e a forma como liberta memória, o que reduz visivelmente o Estabilidade pm regula o modo: dynamic ajusta o número de processos à carga, static mantém um número fixo. pm.max_requests previne o inchaço da memória reiniciando os processos após 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áticos reais.
| Parâmetros | Função | Recomendação do WordPress |
|---|---|---|
| pm | Modo de controlo do processo | dinâmico para carga variável; estático para tráfego permanentemente elevado |
| pm.max_children | Número máximo de trabalhadores em simultâneo | RAM PHP disponível / tamanho do processo × 0,75 |
| pm.max_requests | Reciclagem de processos | 300-1.000; um pouco menos com WooCommerce |
| request_terminate_timeout | Cancelamento de pedidos de longa duração | 60-120 segundos contra cabides |
Dinâmico, a pedido ou estático - qual o modo mais adequado para si?
Selecciono o modo de acordo com o perfil de carga: dinâmico é a minha predefinição, porque ajusta de forma flexível o número de processos activos e, assim, poupa RAM quando há pouca coisa a acontecer. estático Utilizo-a quando a carga é constante e preciso de compromissos rigorosos em termos de latência e débito - por exemplo, durante campanhas ou vendas. a pedido é adequado para servidores com longas fases de inatividade: Os processos são criados apenas quando necessário e terminados novamente após inatividade. A desvantagem é o arranque a frio; o primeiro pedido por novo processo parece mais lento. Para ondemand, defini pm.process_idle_timeout de forma limpa (por exemplo, 10-20s), com dinâmica mantenho iniciar_servidores, servidores de reserva mínimos e máximo de servidores de reserva apertado para que a piscina escale rapidamente mas não „encha“.
Exemplo de configuração para a sua piscina
Na Debian/Ubuntu, o ficheiro de pool está normalmente localizado em /etc/php/8.x/fpm/pool.d/www.conf, o que me dá uma clara Estrutura para personalizações. Defino pm como dinâmico, 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ção, testo a carga e elimino os estrangulamentos antes de aumentar ainda mais os valores. Para obter informações básicas sobre os valores limite, a visão em Otimizar pm.max_children.
pm = dinâmico
pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500
request_terminate_timeout = 90s
Piscinas múltiplas, tomadas e isolamento limpo
Para vários projectos ou funções claramente separadas (frontend vs. admin/REST), configuro piscinas separadas com o seu próprio utilizador e socket. Desta forma, cada pool limita os seus próprios filhos e um outlier não bloqueia os restantes. Em um host, eu prefiro Soquetes Unix comparado ao TCP (listen = /run/php/site.sock) - menor latência, menos sobrecarga. Eu uso TCP entre Nginx/Apache e PHP-FPM em diferentes hosts/contêineres. Eu uso proprietário da lista, listen.group e modo de escuta coerente e, se necessário, aumentar lista.backlog para que pequenos picos de carga não resultem em erros de ligação. Com um pool de administradores dedicados, posso conseguir uma request_terminate_timeout conduzir e pm.max_requests mais baixo sem abrandar o pool de front-end com cache forte.
Reconhecer os sintomas e reagir corretamente
Se o registo de erros indicar regularmente „server reached pm.max_children“, o pool está a limitar o Paralelismo e aumento-o moderadamente. Se ocorrerem 502/504 com alta utilização de swap ao mesmo tempo, eu redefino pm.max_children e diminuo pm.max_requests. Se a CPU aumenta com baixa utilização de RAM, então as consultas ou a lógica PHP estão 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álise do registo com marcas temporais ajudam. Verifico picos conspícuos em relação a cronjobs, índices de pesquisa e acções administrativas.
Estado do FPM e slowlog: diagnóstico preciso
Eu ativo o Estado por pool (pm.status_path) e ler índices como processos activos, máximo de crianças alcançadas, fila de escuta e fila de escuta máxima desligado. Uma fila de listas em permanente crescimento mostra claramente: muito poucos filhos ou backends bloqueados. Eu também defini request_slowlog_timeout (por exemplo, 3-5s) e um registo lento-path. É assim que vejo os traços de pilha dos pedidos que estão a demorar - frequentemente chamadas HTTP externas, consultas complexas do WooCommerce ou manipulações de imagens. Com capturar_saída_dos_trabalhadores os avisos dos trabalhadores são recolhidos nos registos. Com base nestes dados, decido se mais paralelismo ajuda ou se preciso de resolver os estrangulamentos no código/DB.
Controlo: 3-5 dias de avaliação limpa
Após a afinação, monitorizo os picos de carga durante vários dias, porque a curto prazo flutuações enganar. Registo a RAM, swap, 502/504, TTFB e o número de processos activos no estado FPM. Abaixo de 80% de utilização de RAM sem swap e sem filas, estou correto. Se ocorrerem estrangulamentos durante acções como o checkout, a pesquisa ou as importações, ajusto especificamente pm.max_children e pm.max_requests. Cada passo é efectuado em pequenos ajustes e com uma nova medição.
Cálculo da memória em pormenor: RSS, PSS e memória partilhada
A variável de processo é complicada: RSS (Resident Set Size) também contém segmentos partilhados, como a OPcache e as bibliotecas. Por conseguinte, sobrestimo rapidamente o consumo de RAM se me limitar a calcular „RSS × Children“. É melhor usar o PSS-view (Proportional Set Size), que distribui a memória partilhada de forma justa pelos processos - ferramentas como o smem ajudam aqui. O cálculo inclui OPcache (por exemplo, 256 MB + cadeias de caracteres), APCu (por exemplo, 64-128 MB) e o processo mestre. O PHP memory_limit não é uma média, mas o limite superior por pedido; podem ocorrer picos individuais, mas o valor médio conta. Planeio uma reserva para que os picos, as implementações e os cronjobs não desencadeiem imediatamente as trocas e deixo pm.max_requests para limitar o aumento da memória.
Reduzir a carga específica do WordPress
Reduzo primeiro a carga do PHP, antes de aumentar ainda mais as crianças, porque uma taxa de acerto da cache mais rápida poupa tempo real. RAM. As caches de página inteira reduzem drasticamente os pedidos de PHP, o que cria capacidade para checkout, pesquisa e administração. OPcache com memory_consumption de 256 MB acelera o bytecode e alivia o pool. Na prática, mantenho o memory_limit do PHP em 256M para que os plugins individuais não tornem o servidor mais lento. Mais informações sobre gargalos podem ser encontradas no guia PHP Worker como gargalo.
Backends da base de dados e da cache em equilíbrio
Todo PHP worker potencialmente gera um Ligação à base de dados. Se eu aumentar o pm.max_children, a carga simultânea da BD também aumenta. Por conseguinte, verifico o MySQL/MariaDB: max_conexões, buffer (innodb_buffer_pool_size), e o planeador de consultas. O Redis/Memcached deve manter-se em paralelo - clientes máximos, limite de memória e latências. Uma instância do WordPress com 20 filhos activos pode facilmente saturar a BD se várias consultas dispendiosas estiverem a ser executadas em paralelo. É por isso que eu ajusto o banco de dados (índices, consultas lentas) e defino como Caches de objectos persistentes, antes de libertar mais crianças. Isto aumenta o rendimento sem sobrecarregar o backend.
WooCommerce, Cron e Admin: casos especiais
As lojas geram mais pedidos dinâmicos simultâneos, e é por isso que utilizo algo Ar com pm.max_children. Ao mesmo tempo, tendo a diminuir o pm.max_requests para reduzir continuamente o inchaço da memória. Para importações e cronjobs, eu planeio um orçamento adicional ou executo tarefas fora das horas de pico. A área de administração frequentemente tem picos de acessos a curto prazo; o caching fornece menos proteção aqui, então um controle eficiente do pool conta. Se houver sinais de filas de espera, aumento em pequenos passos e monitorizo as métricas imediatamente a seguir.
Contentores, quotas de vCPU e armadilhas OOM
Em contentores e VMs, o foco está no efetivo limite de RAM (cgroups), não no host. Portanto, eu calculo pm.max_children a partir do limite alocado e não a partir de „free -h“. OOMs de contêineres são impiedosos - o kernel termina os processos com força. As quotas de CPU também contam: Mais filhos não ajudam se 1-2 vCPUs limitam o tempo de computação. Como regra geral, eu dimensiono as cargas de trabalho do WordPress com IO pesado para cerca de 2-4× o número de vCPUs; acima disso, as trocas de contexto aumentam, mas não a taxa de transferência real. Em ambientes orquestrados, faço alterações de forma conservadora, observo reinicializações de pods e mantenho sondas de prontidão/vida para que as fases curtas de aquecimento do FPM não sejam contadas como falhas.
Fontes de erro que são frequentemente ignoradas
Muitos problemas não têm origem na piscina, mas sim Plugins, que multiplicam os pedidos ou geram processos longos. As pesquisas indexadas, as regras de rastreio quebradas e os intervalos excessivos de batimentos cardíacos aumentam a carga. Por isso, verifico sempre primeiro os registos, o monitor de consultas e os cabeçalhos de cache. Se a carga ocorrer apenas com determinados URLs, interpreto isso como uma indicação de estrangulamentos de plugins ou modelos. Só quando estes problemas tiverem sido resolvidos é que eu aumento a escala das crianças.
Compreender as sessões, o AJAX administrativo e os bloqueios
WordPress/plugins funcionam parcialmente com Sessões. Os bloqueios de sessão baseados em ficheiros podem serializar pedidos - um único pedido lento bloqueia os restantes pedidos com o mesmo ID de sessão. Mantenho a utilização da sessão reduzida e verifico se as explosões de AJAX do administrador (wp-admin/admin-ajax.php) são desnecessariamente frequentes. O batimento cardíaco deve ser acelerado de forma sensata, caso contrário gera carga sem valor acrescentado. Se ocorrerem bloqueios ou longos acessos a ficheiros, um maior paralelismo não ajudará; o caching, uma E/S de armazenamento mais rápida ou um manipulador de sessão diferente ajudarão aqui. Nos registos, reconheço esses padrões a partir de muitos pedidos semelhantes que começam ao mesmo tempo com tempos de execução invulgarmente longos.
Visão geral dos tempos limite do Nginx, Apache e FastCGI
O servidor Web também estabelece limites que tenho de harmonizar com os valores do FPM, caso contrário, eles desaparecem. Afinação. Com o Nginx, presto atenção ao fastcgi_read_timeout e a processos de trabalho suficientes. No Apache, verifico mpm_event, definições keepalive e timeouts de proxy. Se estes limites não estiverem corretos, os utilizadores reportam timeouts, apesar de o FPM ainda ter capacidade. Os orçamentos de tempo normalizados mantêm o caminho do cliente para o PHP consistente.
Estratégia de implantação, testes e funcionamento
Faço alterações ao pm.max_children passo a passo e testo-as sob carga real. Uma recarga do FPM (graceful) assume as configurações sem quebrar a conexão. Antes de saltos maiores, eu simulo picos (por exemplo, início de venda) e observo fila de escuta, CPU, RAM, 95º-99º percentil de latência e taxas de erro. Documentei as suposições feitas para que os membros posteriores da equipa compreendam porque é que um valor foi escolhido desta forma. Defino alarmes para: swap > 0, „max children reached“ no estado, aumento de 502/504 e latência da BD. Isso garante que a plataforma permaneça estável mesmo meses depois, quando o tráfego e a combinação de plug-ins mudam.
Brevemente resumido
Definição incorrecta PHP-FPM-Os filhos atrasam o WordPress, seja nas filas ou no limite de RAM. Determino o tamanho do processo, reservo memória para os serviços do sistema e defino pm.max_children com buffer. Em seguida, verifico pm.max_requests, request_terminate_timeout e o modo pm = dinâmico ou estático de acordo com o perfil de carga. Caching, OPcache e plugins limpos reduzem visivelmente o número de pedidos de PHP. Se implementar estes passos de forma consistente, manterá as páginas responsivas e o servidor fiável.
