Cálculo Matemático de pm.max_children en PHP-FPM para Servidores Ubuntu y Debian

Uno de los errores de administración de sistemas más extendidos en servidores web Linux es dejar la directiva pm.max_children con los valores por defecto del paquete de instalación (habitualmente 5 en configuraciones genéricas, o 50 sin contrastar con la memoria física del equipo).

Las consecuencias de un valor erróneo son letales para cualquier negocio:

• Si max_children es demasiado bajo: las peticiones concurrentes se encolan, el TTFB se dispara a más de 10 segundos y el servidor devuelve el temido error HTTP 504 Gateway Timeout.
• Si max_children es demasiado alto: los procesos concurrentes de PHP saturan la memoria RAM física, el sistema operativo activa el temido proceso OOM Killer (Out Of Memory) y el kernel mata repentinamente el servicio MySQL o el propio maestro de PHP-FPM.

La Fórmula Matemática de Asignación de Recursos

Para calcular el valor óptimo de procesos hijos máximos, debemos aplicar una fórmula rigurosa basada en el consumo real de su aplicación en producción:

$$\text{pm.max_children} = \frac{\text{RAM Total} - \text{RAM Reservada (SO, MySQL, Redis, Nginx)}}{\text{Consumo Medio de un Proceso PHP}}$$

1. Medir el Consumo Medio Real de PHP en su Servidor

No adivine el consumo de memoria; mídalo en directo mientras el sitio recibe tráfico representativo mediante este comando en terminal:

ps --no-headers -o "rss,cmd" -C php-fpm8.3 | awk '{ sum+=$1; count++ } END { if (count>0) print "Consumo medio: " sum/count/1024 " MB (de " count " procesos)" }'

• En sitios WordPress/WooCommerce ligeros, el valor medio suele rondar los 60 - 90 MB por worker.
• En tiendas con plugins complejos de analítica o ERPs integrados, el consumo puede elevarse a 120 - 180 MB por proceso.

2. Ejemplo Práctico en un VPS de 16 GB de RAM

Supongamos un servidor virtual en Arsys u OVH con las siguientes especificaciones:

• RAM Total: 16 GB (16.384 MB).
• Reserva para el Sistema Operativo y Nginx: 1.500 MB.
• Reserva para MySQL / MariaDB (Buffer Pool): 6.000 MB.
• Reserva para Redis Object Cache: 1.000 MB.
• RAM disponible para PHP-FPM: $16.384 - 8.500 = \mathbf{7.884\text{ MB}}$.
• Consumo medio medido por proceso PHP: 100 MB.

$$\text{pm.max_children} = \frac{7884}{100} \approx \mathbf{78}$$

3. Configuración del Pool en /etc/php/8.3/fpm/pool.d/www.conf

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data

; Selección del gestor de procesos: dynamic o ondemand
pm = dynamic
pm.max_children = 78
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30
pm.max_requests = 1000

; Prevención de hilos colgados
request_terminate_timeout = 60s

Por Qué pm.max_requests = 1000 Es Vital

PHP no está exento de pequeñas fugas de memoria (memory leaks) provocadas por extensiones o librerías externas. La directiva pm.max_requests = 1000 obliga a cada proceso hijo a destruirse y liberarse limpiamente tras atender 1.000 peticiones, devolviendo toda la memoria física al sistema operativo y previniendo la degradación lenta del servidor tras semanas de funcionamiento ininterrumpido.

🔗 Diagnósticos Técnicos Interconectados & Malla de Arquitectura:

Los cuellos de botella en servidores y pasarelas de pago nunca ocurren de forma aislada. La latencia del servidor, las consultas SQL y el rendimiento en el checkout están totalmente interconectados:

• Optimización de Redis Object Cache y Bloqueos de Sesión: Eliminar retrasos en el carrito de compra y errores 504 en tiendas online.
• Laravel Octane con Swoole en Servidores Bare-Metal: Aumentar la capacidad de peticiones por segundo en aplicaciones corporativas.
• Resolución de Fallos en Webhooks de Redsys y Bizum: Garantizar la confirmación instantánea de pagos sin perder carritos en WooCommerce.