Cómo corregir picos de CPU y PHP‑FPM slowlog en servidores Linux durante picos: diagnóstico y ajustes

Por · Publicado el · 7 min de lectura

Rack de servidores con cables y monitor en primer plano, iluminación azul
Escena de infraestructura que remite a diagnóstico y operación de servidores Foto: panumas nikhomkhai / Pexels

Corregir picos de CPU y PHP‑FPM slowlog en servidores Linux es urgente cuando empiezan 502/504 y cae el tráfico. En esta guía verás cómo diagnosticar la raíz del problema, ajustar PHP‑FPM y la aplicación, y montar una monitorización mínima para evitar que vuelva a ocurrir —con prioridades claras para estabilizar el entorno bajo carga.

Señales de que el cuello de botella es real (y dónde mirar primero)

En los picos, los síntomas aparecen en cadena. Valida rápido para evitar hipótesis equivocadas.

Observa CPU user/sys/wa, load average por núcleo, la cola del FPM y los tiempos de respuesta en Nginx. Correlaciona con los horarios pico del negocio. Usa paneles con Prometheus y Grafana para visualizar la saturación por componente.

  • CPU al 90–100% durante varios minutos y load average por encima del número de vCPUs.
  • Aumento de 502/504 y upstream_response_time alto en Nginx.
  • Cola del PHP‑FPM en crecimiento (listen.queue).
  • Disco con alto I/O wait (iowait) y picos de context switches (cs).
  • Slowlog registrando backtraces repetidos del mismo endpoint.
  • Colas internas (jobs) retrasadas y cron jobs solapándose.
Síntoma Causa probable Próximo paso
CPU alta con iowait elevado I/O de disco o storage lento Verificar iowait y mover sesiones/cache a memoria
Cola del FPM en aumento Pocos workers o ejecución lenta Ajustar pm.* y analizar slowlog
Solo algunos endpoints lentos SQL pesado, N+1 o cache ausente Optimizar consultas e habilitar cache
Latencia irregular GC de PHP y autoload excesivo Revisar uso de memoria y autoloader
Load alto con CPU baja Bloqueos, I/O o colas del kernel Chequear iowait, run queue y locks

Por qué ocurre en el horario pico: cuellos de botella típicos

En el pico, el sistema alcanza límites de concurrencia. Pequeñas ineficiencias generan colas.

Las causas más comunes involucran configuración del PHP‑FPM, latencia de base de datos/IO y coste de CPU por request.

  • pm.max_children subdimensionado o gestor de procesos mal elegido (ondemand vs dynamic).
  • Queries lentas y N+1 que elevan el tiempo medio de respuesta (veáse diagnóstico de N+1 y GC en API REST: picos de latencia).
  • Opcache desactivado, con poco espacio o fragmentado.
  • Sesiones en disco, storage en red lento o logs síncronos.
  • Cron jobs y workers compitiendo con el tráfico por CPU.
  • Autoload y reflexión pesados en rutas calientes.

Diagnóstico de arriba hacia abajo: sistema → FPM → aplicación

Enmarca el problema antes de cambiar números. Seguir este orden evita ruido en el diagnóstico.

En el sistema, diferencia CPU de cálculo de espera por I/O. En FPM, mira la cola y el estado de los workers. En la aplicación, identifica handlers y queries calientes.

  • Sistema: CPU user/sys/wa/st, load por vCPU, interrupciones y steal.
  • PHP‑FPM: estado de workers (Idle, Running, Listen queue).
  • Nginx: upstream_response_time, conteo de 502/504 y picos por ruta.
  • Base de datos: consultas lentas y locks durante el pico.
  • Correlaciona con logs estructurados y correlación.

Activa e interpreta el PHP‑FPM slowlog con seguridad

El slowlog muestra el backtrace de las peticiones que superan un umbral. Úsalo en ventanas cortas en producción.

Define un timeout que capture las rutas lentas sin generar ruido. Centraliza logs para análisis con herramientas como Fluentd + Elasticsearch.

Consulta la documentación oficial de FPM para detalles de las directivas.

  • Habilitar slowlog en el pool más crítico durante algunos minutos.
  • Aumentar ligeramente el timeout hasta capturar casos representativos.
  • Priorizar patrones repetidos en el backtrace en vez de casos aislados.
  • Cruzar con el acceso de Nginx para encontrar la ruta y los 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 de PHP‑FPM para tráfico pico (sin tirar números al azar)

Dimensiona los workers según el consumo real de memoria por proceso, no por el límite teórico memory_limit.

Elige el process manager según el perfil de tráfico. Dynamic responde mejor a picos previsibles; ondemand ahorra RAM en baja, pero puede sufrir cold starts.

  • Estimar pm.max_children: RAM disponible para PHP ÷ RAM media por worker, con margen para kernel, caches y base de datos.
  • pm = dynamic con start/min/max compatibles con tu RPS de pico.
  • pm.max_requests para reciclar procesos y evitar fugas constantes (ver fuga de memoria en PHP‑FPM).
  • listen.backlog y somaxconn suficientes para colas cortas sin pérdida.
  • request_terminate_timeout para matar outliers que monopolizan 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

Optimizaciones de aplicación que más alivian CPU

Con el cuello de botella aislado, corrige lo que más pesa por request. Muchas mejoras son rápidas y seguras.

Enfócate en las rutas calientes vistas en el slowlog y en las métricas de la app.

  • Habilitar y dimensionar Opcache (memoria, internamiento de strings, revalidación).
  • Optimizar el autoloader: generar classmap y evitar scans innecesarios.
  • Eliminar N+1 y reescribir consultas caras; añadir índices adecuados (optimización de consultas PostgreSQL).
  • Cachear respuestas y fragmentos para rutas calientes; un TTL corto es mejor que no tener nada.
  • Reducir trabajo por request: precomputar, memoizar y evitar regex costosas.
  • Separar workers/cron pesados del pico de tráfico o limitar su concurrencia.
; 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

Monitorea y evita recurrencias

Sin visibilidad, el problema vuelve. Instrumenta sistema, FPM y aplicación, y crea alertas simples que disparen antes del incidente.

Adopta paneles centrados en síntomas de saturación y en las rutas calientes.

  • Métricas de sistema: CPU user/sys/wa, load por vCPU, iowait, run queue.
  • FPM: workers por estado, listen.queue, spawn rate y 5xx por ruta.
  • Logs correlacionados por request_id y muestras de slowlog archivadas.
  • APM/tracing para rutas críticas y jobs en horarios pico.
  • Pruebas de carga periódicas con datos realistas y caches fríos/calientes.

Preguntas frecuentes

¿Qué muestra realmente el PHP‑FPM slowlog?

Registra un backtrace cuando una petición supera request_slowlog_timeout. Así ves qué funciones y fragmentos de código estaban en ejecución. Actívalo en ventanas cortas para evitar exceso de logs y céntrate en patrones repetidos.

¿pm.dynamic o pm.ondemand es mejor para picos?

Depende del perfil. Dynamic mantiene procesos listos y maneja mejor picos previsibles. Ondemand ahorra RAM en baja, pero puede sufrir cold starts cuando la carga sube rápido. Prueba con tu tráfico y monitorea la cola del FPM.

¿Cómo calcular pm.max_children con seguridad?

Mide la memoria media de un worker bajo carga real y deja margen para kernel, caches, Nginx y base de datos. Divide la RAM disponible para PHP por el consumo medio por worker. Evita usar solo memory_limit teórico; es un techo, no el uso real.

¿Las consultas lentas pueden causar picos de CPU?

Sí. Queries no optimizadas pueden aumentar el tiempo por request y mantener workers ocupados, incrementando la cola y el uso de CPU. Corrige N+1, crea índices, revisa planes de ejecución y valora cachear resultados caros en rutas calientes.

¿Cuándo considerar escalar servidores?

Después de optimizar y dimensionar correctamente FPM, Opcache y las rutas calientes. Si la utilización media en pico sigue alta con colas crecientes, añade vCPUs y RAM o escala horizontalmente. Las pruebas de carga ayudan a validar el punto de saturación.

¿Quieres estabilizar tus picos de tráfico?

Si necesitas un análisis técnico para diagnosticar picos de CPU y slowlog de PHP‑FPM y definir ajustes seguros, hablemos sobre tu caso.

Agendar conversación

Ver también