Más procesos PHP-FPM no siempre soportan más tráfico

¿Tu WordPress se cae justo cuando aumentas pm.max_children? Más workers atienden más peticiones, pero también pueden agotar la RAM, activar swap y trasladar el cuello de botella a Nginx, MySQL o PHP-FPM.

Mide el pool antes de cambiar límites

Mide el estado actual para saber qué límite tocar sin adivinar.

Registra una línea base útil

Anota latencia, errores y consumo durante un pico normal, incluyendo portada, ficha, carrito, pago y /wp-admin/ en WooCommerce, porque una página cacheada consume mucho menos que un checkout con sesión.

Bash free -h vmstat 1 5 uptime sudo ps -eo pid,%cpu,rss,cmd --sort=-rss | grep '[p]hp-fpm' sudo tail -n 100 /var/log/php8.2-fpm.log sudo tail -n 100 /var/log/nginx/error.log

Calcula PSS y detecta saturación

Calcula el PSS de varios workers bajo carga: reparte la memoria compartida entre procesos y es una referencia más honesta que RSS cuando OPcache está activo.

Bash for p in $(pgrep -f 'php-fpm: pool'); do printf "PID %s: " "$p" awk '/^Pss:/{sum+=$2} END{print sum " KB"}' /proc/$p/smaps_rollup done

Calcula workers según RAM y carga real

Calcula pm.max_children con la memoria reservada para evitar que PHP-FPM consuma toda la RAM.

Reserva memoria antes de dividir

La fórmula es: workers máximos = RAM disponible para PHP-FPM ÷ PSS prudente de un worker. Resta primero memoria para sistema, Nginx, MySQL, caché y margen operativo; si quedan 700 MB y el PSS alto es 70 MB, el techo es 10, pero configurar 8 suele ser más prudente.

Elige el gestor de procesos adecuado

Elige pm dynamic para WordPress y WooCommerce con tráfico variable: conserva algunos workers preparados y crea otros cuando hace falta.

Ajusta el pool sin copiar cifras

Edita el pool según tu cálculo y deja entre un 15% y un 25% de RAM libre; pm.max_requests puede reciclar procesos que retienen memoria, pero no corrige un plugin defectuoso.

Ini pm = dynamic pm.max_children = 8 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 4 pm.max_requests = 500 listen.backlog = 1024

Coordina nginx, OPcache y MySQL

Alinea Nginx, PHP-FPM y base de datos para que un límite nuevo no cree otra cola.

Revisa socket, cola y tiempos

Usa socket Unix cuando Nginx y PHP-FPM están en la misma máquina y verifica que fastcgi_pass coincida con el listen del pool; un 502 suele indicar que Nginx no obtuvo respuesta válida y un 504 que esperó demasiado.

Nginx fastcgi_pass unix:/run/php/php8.2-fpm.sock; fastcgi_connect_timeout 10s; fastcgi_send_timeout 60s; fastcgi_read_timeout 60s;

Activa caché de opcode y slowlog

Activa OPcache para evitar traducir PHP en cada petición y configura el slowlog para localizar scripts, cron, consultas o llamadas externas que mantienen ocupados los workers.

Ini opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=20000 request_slowlog_timeout = 5s slowlog = /var/log/php8.2-fpm-slow.log

Los timeouts y buffers de FastCGI deben ajustarse a partir de síntomas, no con cifras universales. Si el log de Nginx muestra upstream sent too big header, revisa primero el tamaño de las cabeceras, cookies o plugins y, solo entonces, valora fastcgi_buffer_size y fastcgi_buffers; cada buffer adicional puede elevar la memoria usada durante respuestas concurrentes. fastcgi_keep_conn on puede reducir el coste de abrir conexiones FastCGI en cargas sostenidas, aunque su impacto suele ser menor con socket Unix local.

Si los workers PHP permanecen ocupados y la latencia p95 crece sin que la CPU de PHP esté al límite, correlaciona el slowlog con las consultas lentas de MySQL: aumentar pm.max_children no resolverá una base de datos bloqueada o saturada.

Verifica la configuración de PHP-FPM efectiva antes de asumir que un cambio en php.ini se ha aplicado. php --ini describe normalmente el SAPI de línea de comandos, que puede cargar archivos distintos de FPM; comprueba la salida de php-fpm8.2 -i o de una página de diagnóstico temporal y protegida. Los valores definidos en el pool mediante php_admin_value[memory_limit] tienen prioridad y no pueden modificarse con ini_set() desde WordPress. Revisa también que OPcache esté activo para FPM, no solo para CLI, y que la configuración de PHP-FPM use la versión instalada.

De este modo, el consumo de memoria de los workers PHP se interpreta con los límites reales y pm.max_requests se ajusta sobre procesos que ejecutan la misma configuración en producción.

Aísla pools y despliega con rollback

Separa cada WordPress en su propio pool para impedir que un sitio lento consuma todos los workers disponibles.

Crea un pool por cada sitio

Crea un archivo por sitio con usuario, socket y límites propios, y comprueba que Nginx pueda acceder al socket sin abrir permisos innecesarios.

Ini [cliente1] user = cliente1 listen = /run/php/cliente1.sock listen.owner = www-data listen.group = www-data listen.mode = 0660 pm = dynamic pm.max_children = 4 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 2 pm.max_requests = 400

Prueba, recarga y revierte

Valida primero con sudo php-fpm8.2 -t y sudo nginx -t; después aplica el cambio en staging o un pool secundario, prueba rutas reales y compara latencia p95, errores, RAM y cola antes de modificar producción.

En entornos con PHP 8.x dentro de Docker o Kubernetes, calcula pm.max_children con el límite de memoria del contenedor, no con la RAM total del nodo. Un pod limitado a 512 MB puede ser finalizado por OOM aunque el servidor anfitrión tenga memoria libre. El socket Unix es eficiente cuando Nginx y PHP-FPM comparten contenedor, volumen y host; si están en contenedores, pods o máquinas diferentes, usa TCP, por ejemplo listen = 9000 y fastcgi_pass php-fpm:9000, protegido por la red interna y políticas de acceso.

Define solicitudes y límites de CPU y memoria, verifica los reinicios por OOM y replica los pods solo después de confirmar que MySQL, Redis y los servicios externos soportan el nuevo throughput.

Lo que más preguntan

¿Cuántos workers necesito en un VPS de 2 GB?

Un VPS de 2 GB necesita calcular workers tras reservar memoria para sistema, Nginx, MySQL, caché y margen. Divide la RAM restante entre el PSS alto de un worker y redondea a la baja. En muchas tiendas pequeñas el resultado prudente queda entre 4 y 10, pero depende del consumo medido.

¿Uso pm static, dynamic u ondemand?

pm dynamic suele encajar en WordPress con tráfico variable porque conserva workers preparados sin fijarlos todos. pm static sirve con carga continua y RAM abundante. pm ondemand conviene en webs casi inactivas, no en checkouts frecuentes.

¿Por qué aparece server reached pm.max_children?

Ese aviso indica que todos los workers del pool estaban ocupados y nuevas peticiones tuvieron que esperar. Puede requerir más workers, pero también señalar consultas lentas, cron, APIs externas o falta de caché. Revisa el slowlog antes de aumentar el límite.

¿Qué memory_limit debo poner en WordPress?

memory_limit debe cubrir la petición más pesada sin permitir que varios workers agoten la RAM total. Valores entre 128 MB y 256 MB son habituales, pero un WooCommerce con importaciones puede requerir más de forma puntual. No eleves ese límite sin recalcular pm.max_children.

¿Cada cuánto conviene reiniciar PHP-FPM?

PHP-FPM debe recargarse tras cambios de configuración o despliegues, no como remedio periódico para la lentitud. Reinicios frecuentes suelen ocultar una fuga de memoria o un proceso largo. Usa pm.max_requests y el slowlog para localizar la causa.

Mantén margen y valida cada cambio

El ajuste correcto es el que sostiene la carga sin cola persistente, swap ni errores.

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.