PHP-FPM Tuning: Parâmetros que Realmente Importam para Alta Performance

PHP-FPM tuning. Se o PHP-FPM estiver mal ajustado, não existe Nginx, Apache, Redis ou NVMe que salve. O oposto também é verdade: um PHP-FPM bem dimensionado reduz CPU, RAM, latência e erros 502/504.

1️⃣ pm – o modelo de gerenciamento de processos (CRÍTICO)

🔹 pm = dynamic (padrão e mais comum)

Bom para a maioria dos servidores.

pm = dynamic

✔ Cria processos conforme a demanda
✖ Pode oscilar em picos se mal dimensionado

🔹 pm = ondemand

Ideal para baixo ou médio tráfego, APIs ou múltiplos pools.

pm = ondemand

✔ Menor uso de RAM
✖ Primeiro request após idle é mais lento

🔹 pm = static

Para alto tráfego previsível (sites grandes, ecommerce, SaaS).

pm = static

✔ Latência mínima
✖ RAM sempre alocada (sem perdão)

👉 Produção com tráfego alto e estável? static
👉 Ambiente misto ou WordPress comum? dynamic

2️⃣ pm.max_children – o parâmetro mais importante de TODOS

Esse aqui define quantas requisições PHP simultâneas seu servidor aguenta.

Fórmula correta (sem achismo):

Visite nosso post clicando aqui PHP-FPM: Como Calcular pm.max_children Corretamente

Como medir o consumo real:

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { print sum/NR/1024 " MB" }'

3️⃣ pm.start_servers, pm.min_spare_servers, pm.max_spare_servers

Só importam se você usa pm = dynamic.

Valores realistas:

pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 30

📌 Regra prática:

• start_servers ≈ tráfego médio
• max_spare_servers ≈ 30% de max_children

❌ Valores muito baixos = latência em pico
❌ Valores altos demais = RAM desperdiçada

4️⃣ request_terminate_timeout – mata PHP travado

Esse parâmetro evita processos PHP zumbis.

request_terminate_timeout = 60s

✔ Protege contra:

• Plugins bugados
• Queries travadas
• APIs lentas

👉 WordPress padrão: 30–60s
👉 WooCommerce pesado: 90s

5️⃣ pm.max_requests – reciclagem inteligente

Evita vazamento de memória em scripts mal escritos.

pm.max_requests = 500

✔ Reinicia o worker após X requisições
✔ Estabiliza uso de RAM ao longo do tempo

Valores comuns:

• 300 a 1000 (WordPress costuma ficar bem em 500)

6️⃣ listen.backlog – fila antes do desastre

listen.backlog = 8192

Se o backlog for pequeno:

• O kernel recusa conexões
• Você vê picos de 502 mesmo com CPU livre

7️⃣ rlimit_files – subestimado e perigoso

rlimit_files = 65535

Sem isso:

• “Too many open files”
• PHP cai em tráfego alto
• Logs não explicam nada

8️⃣ OPcache (não é PHP-FPM, mas manda no desempenho)

Sem OPcache bem ajustado, todo tuning acima perde valor.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=100000
opcache.validate_timestamps=0
opcache.revalidate_freq=0

🚀 Impacto real:

• Menos CPU
• Resposta mais rápida
• Menos processos PHP necessários

9️⃣ O que NÃO importa (ou quase)

❌ pm.process_idle_timeout (quase irrelevante)
❌ Ajustes extremos de nice
❌ Criar dezenas de pools sem necessidade
❌ “Tunings mágicos” copiados de blog genérico

1️⃣0️⃣ Exemplo de pool PHP-FPM realista (WordPress produção)

[www]
user = php-fpm
group = php-fpm

listen = /run/php-fpm/www.sock
listen.owner = nginx
listen.group = nginx
listen.mode = 0660
listen.backlog = 8192

pm = dynamic
pm.max_children = 100
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 30
pm.max_requests = 500

request_terminate_timeout = 60s
rlimit_files = 65535

🔥 Checklist final de tuning correto

✔ Mediu consumo real de PHP
✔ Calculou pm.max_children corretamente
✔ Limitou tempo de execução
✔ OPcache bem configurado
✔ Evitou overcommit de RAM

FAQ – PHP-FPM Tuning