Tuning do pool do PHP-FPM em produção — a decisão static vs dynamic vs ondemand

O problema de performance de PHP mais comum em auditorias que chegam: PHP-FPM em modo dynamic com dimensionamento default apropriado para um VPS de 1 GB em 2014, rodando em uma máquina de 16 GB, enquanto a aplicação morre de fome com 5 children. O outro comum: pm = ondemand num site de produção com RPS alto que paga o custo de fork a cada burst.

Este é o tuning de pool que aplicamos no onboarding, a disciplina de slowlog que aplicamos depois, e como saber se está funcionando.

O pool que costumamos entregar

; /etc/php/8.3/fpm/pool.d/www.conf
pm = static
pm.max_children = 50
pm.max_requests = 1000
 
request_terminate_timeout = 60s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
 
pm.status_path = /fpm-status
ping.path = /fpm-ping

static uma vez que você sabe o max_children certo — sem custo de fork em bursts, memória previsível. Calcule max_children como (RAM disponível - overhead do SO - outros serviços) / memória por processo. Meça a memória por processo sob carga, não em repouso.

O artigo completo cobre:

• Os modos pm — static vs dynamic vs ondemand, e quando cada um está certo
• Calcular pm.max_children a partir da memória por processo observada sob carga
• pm.max_requests e por que colocá-lo em 0 (default) está errado
• Tuning do slowlog — o threshold de 5 segundos e os padrões que ele traz à tona
• O wiring de /fpm-status no Nginx e o que cada métrica significa
• Coordenar o tuning do PHP-FPM com a config OPcache + JIT no mesmo host

Entregamos essa configuração em cada stack PHP gerenciada.