Como corrigir picos de CPU e PHP-FPM slowlog em servidor Linux durante horários de pico: diagnóstico e ajustes

Por · Publicado em · 7 min de leitura

Rack de servidores com cabos e monitor em primeiro plano, iluminação azul
Cena de infraestrutura que remete a diagnóstico e operação de servidores Foto: panumas nikhomkhai / Pexels

Como corrigir picos de CPU e PHP-FPM slowlog em servidor Linux durante horários de pico é urgente quando 502/504 surgem e o tráfego cai. Neste guia, você aprende a diagnosticar a raiz do problema, ajustar o PHP-FPM e a aplicação, e montar um monitoramento mínimo para evitar recorrência — com prioridades claras para estabilizar o ambiente sob carga.

Sinais de que o gargalo é real (e onde olhar primeiro)

Em pico, sintomas aparecem em cadeia. Valide rapidamente para evitar hipóteses erradas.

Observe CPU user/sys/wa, load average por núcleo, fila do FPM e tempo de resposta no Nginx. Correlacione com os horários de pico do negócio. Use painéis com Prometheus e Grafana para visualizar a saturação por componente.

  • CPU 90–100% por vários minutos e load average acima do número de vCPUs.
  • Aumento de 502/504 e upstream_response_time alto no Nginx.
  • Fila do PHP‑FPM crescendo (listen.queue).
  • Disco com alto I/O wait (wa) e picos de contexto (cs).
  • Slowlog registrando backtraces repetidos do mesmo endpoint.
  • Filas internas (jobs) atrasando e cron jobs sobrepostos.
Sintoma Causa provável Próximo passo
CPU alta com wa elevado I/O do disco ou storage lento Verificar iowait e mover sessões/cache para memória
Fila do FPM aumenta Poucos workers ou execução lenta Ajustar pm.* e analisar slowlog
Apenas alguns endpoints lentos SQL pesado, N+1 ou cache ausente Otimizar queries e habilitar cache
Latência irregular GC do PHP e autoload excessivo Rever uso de memória e autoloader
Load alto, CPU baixa Bloqueios, I/O ou filas de kernel Checar iowait, run queue e locks

Por que acontece no horário de pico? Gargalos típicos

No pico, o sistema atinge limites de concorrência. Pequenas ineficiências viram fila.

As causas mais comuns envolvem configuração do PHP‑FPM, latência de banco/IO e custo de CPU por requisição.

  • pm.max_children subdimensionado ou pm mal escolhido (ondemand vs dynamic).
  • Queries lentas e N+1 elevando tempo médio de request (veja diagnóstico de N+1 e GC em APIs PHP).
  • Opcache desativado, pequeno ou fragmentado.
  • Sessões em disco, storage de rede lento ou logs síncronos.
  • Cron jobs e workers competindo com o tráfego por CPU.
  • Autoload e reflexão pesados em rotas quentes.

Diagnóstico de cima para baixo: sistema → FPM → app

Enquadre o gargalo antes de mudar números. Seguir a ordem evita ruído no diagnóstico.

No sistema, diferencie CPU compute de espera por I/O. No FPM, veja fila e estado dos workers. Na aplicação, identifique handlers e queries quentes.

  • Sistema: CPU user/sys/wa/st, load por vCPU, interrupções e roubo (steal).
  • PHP‑FPM: status de workers (Idle, Running, Listen queue).
  • Nginx: upstream_response_time, contagem de 502/504 e picos por rota.
  • Banco: slow queries e locks durante o pico.
  • Correlacione com logs estruturados e correlação.

Ative e interprete o PHP-FPM slowlog com segurança

O slowlog mostra o backtrace das requisições acima de um limite. Use por janelas curtas em produção.

Defina um timeout que capture as rotas lentas sem gerar ruído. Centralize logs para análise com ferramentas como Fluentd + Elasticsearch.

Consulte a documentação oficial do FPM para detalhes das diretivas.

  • Habilitar slowlog no pool mais crítico por alguns minutos.
  • Aumentar levemente o timeout até capturar casos representativos.
  • Priorizar padrões repetidos no backtrace em vez de casos isolados.
  • Cruzar com o acesso do Nginx para achar a rota e parâmetros.
; Exemplo: /etc/php/8.x/fpm/pool.d/www.conf
; Ajuste caminhos e versão de acordo com seu ambiente
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/www-slow.log
pm.status_path = /status
catch_workers_output = yes

Ajustes do PHP-FPM para tráfego de pico (sem chute)

Dimensione workers pelo consumo real de memória por processo, não pelo limite teórico do memory_limit.

Escolha o process manager conforme o perfil de tráfego. Dynamic atende picos previsíveis; ondemand economiza RAM em baixa, mas pode sofrer com cold starts.

  • Estimar pm.max_children: RAM disponível para PHP ÷ RAM média por worker, com folga para kernel, caches e banco.
  • pm = dynamic com start/min/max compatíveis com seu RPS de pico.
  • pm.max_requests para reciclar processos e evitar vazamentos constantes (veja vazamento de memória no PHP‑FPM).
  • listen.backlog e somaxconn suficientes para filas curtas sem perda.
  • request_terminate_timeout para matar outliers que monopolizam CPU.
; Exemplo didático, ajuste pelos seus números
pm = dynamic
pm.max_children = 48
pm.start_servers = 8
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500
request_terminate_timeout = 30s

Otimizações de aplicação que mais aliviam CPU

Com o gargalo isolado, corrija o que mais pesa por request. Muitas melhorias são rápidas e seguras.

Foque nas rotas quentes vistas no slowlog e nas métricas de app.

  • Habilitar e dimensionar o Opcache (memória, strings internadas, revalidação).
  • Otimizar autoloader: classmap gerada e evitar scans desnecessários.
  • Eliminar N+1 e reescrever queries caras; introduzir índices adequados (otimização de consultas PostgreSQL).
  • Cache de respostas e fragmentos para rotas quentes; TTL curto é melhor que nada.
  • Redução de trabalho por request: pré‑computar, memoizar e evitar regex custosas.
  • Separar workers/cron pesados do pico de tráfego ou limitar concorrência.
; Opcache (php.ini) — valores ilustrativos, ajuste medindo
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Monitore e previna recorrência

Sem visibilidade, o problema volta. Instrumente sistema, FPM e aplicação, e gere alertas simples que disparam antes do incidente.

Adote painéis focados em sintomas de saturação e nas rotas quentes.

  • Métricas de sistema: CPU user/sys/wa, load por vCPU, iowait, run queue.
  • FPM: workers por estado, listen.queue, spawn rate e 5xx por rota.
  • Logs correlacionados por request_id e amostras de slowlog arquivadas.
  • APM/tracing para rotas críticas e jobs em horários de pico.
  • Testes de carga periódicos com dados realistas e caches frios/quentes.

Perguntas frequentes

O que o PHP-FPM slowlog realmente mostra?

Ele registra um backtrace quando uma requisição ultrapassa request_slowlog_timeout. Assim, você vê quais funções e trechos de código estavam em execução. Ative por janelas curtas para evitar excesso de log e foque em padrões repetidos.

pm.dynamic ou pm.ondemand é melhor para picos?

Depende do perfil. Dynamic mantém processos prontos e lida melhor com picos previsíveis. Ondemand economiza RAM em baixa, mas pode sofrer com cold starts quando a carga sobe rápido. Teste com seu tráfego e monitore a fila do FPM.

Como calcular pm.max_children com segurança?

Meça a memória média de um worker sob carga real e deixe folga para kernel, caches, Nginx e banco. Divida a RAM disponível para PHP pelo consumo médio por worker. Evite usar apenas o memory_limit teórico, pois é um teto, não o uso real.

Slow queries podem causar picos de CPU?

Sim. Queries não otimizadas podem aumentar o tempo de request e segurar workers ocupados, elevando a fila e o uso de CPU. Corrija N+1, crie índices, revise planos de execução e avalie cache para resultados caros em rotas quentes.

Quando considerar escalar servidores?

Depois de otimizar e dimensionar corretamente FPM, Opcache e as rotas quentes. Se a utilização média em pico continua alta com filas crescentes, acrescente vCPUs e RAM ou escale horizontalmente. Teste de carga ajuda a validar o ponto de saturação.

Quer estabilizar seu pico de tráfego?

Se você precisa de um olhar técnico para diagnosticar picos de CPU e slowlog do PHP-FPM e definir ajustes seguros, vamos conversar sobre o seu caso.

Agendar conversa

Veja também