Ir al contenido 
PHP-FPM Niños deciden en WordPress si las peticiones se ejecutan sin problemas o se quedan atascadas en la cola. Le mostraré cómo incorrecto pm.max_hijos-los valores bloquean las páginas, se comen la RAM y cómo calculo los valores limpios.
Puntos centrales
Antes de profundizar más, resumiré brevemente los mensajes clave:
- pm.max_hijos determina cuántas peticiones PHP simultáneas se están ejecutando.
- Demasiado poco Los niños generan colas, 502/504 y un alto TTFB.
- Demasiado conduce a cuellos de botella de RAM, swap y muertes OOM.
- FórmulaRAM PHP disponible / tamaño del proceso × 0,7-0,8.
- Iterativo El ajuste con supervisión ofrece el mejor rendimiento a largo plazo.
Por qué se bloquean las páginas incorrectas de PHP-FPM Children
Cada solicitud dinámica de WordPress requiere su propio Trabajador, y son precisamente estos procesos los que el pool controla a través de pm.max_children. Si establezco el valor demasiado bajo, las peticiones se amontonan en una cola y el TTFB aumenta notablemente. Si pongo el valor demasiado alto, cada proceso hijo usa RAM adicional y el servidor cambia a swap. Todo se ralentiza en el swap hasta que Apache o Nginx reportan 502/504 o el OOM killer termina los procesos. El rendimiento saludable sólo se consigue cuando el número de hijos coincide con el presupuesto real de RAM y la carga del proyecto.
La fórmula para pm.max_children en la práctica
Empiezo con la fórmula simple: RAM disponible para PHP dividido por el tamaño medio de un proceso hijo, multiplicado por un Factor de seguridad Determino la RAM por proceso con ps y la columna RSS; para las pilas típicas de WordPress, 50-250 MB suele ser correcto. En un servidor de 4 GB, reservo memoria para Linux, la base de datos y los servicios de caché, dejando alrededor de 1,5-2 GB para PHP permanecen. Por ejemplo, si la media del proceso es de 100 MB, 2.000 / 100 × 0,75 = 15 niños. Esta cifra sirve como punto de partida, que refino en función del perfil de carga, la caché y la combinación de plugins.
Valores iniciales para configuraciones típicas de WordPress
Para blogs pequeños con 2 GB de RAM, 8 hijos, pm = dynamic y un pm.max_requests de aprox. 800. Para proyectos de tamaño medio con 4 GB de RAM, establezco 12 hijos, start_servers 4, min_spare_servers 4. Las tiendas grandes con 8 GB de RAM o más se benefician de 21-40 hijos; si la carga es permanentemente alta, pm = static puede garantizar un rendimiento constante. A continuación, compruebo la relación entre la utilización de la CPU, la utilización de la RAM y los tiempos de respuesta para realizar ajustes precisos. Si quieres profundizar, puedes encontrar información de fondo en configuración óptima de PHP-FPM.
Medición de procesos: cómo determinar las necesidades de RAM
Primero determino el tamaño real de los procesos antes de fijar los valores, porque las bolas de cristal no ayudan en este caso y cuestan dinero. Actuación. El comando ps -ylC php-fpm -sort:rss devuelve los tamaños RSS, que monitorizo durante unos minutos. Los procesos suelen crecer durante las actualizaciones o las tareas cron, por lo que incluyo los picos en el cálculo. También utilizo htop y free -h para comprobar las reservas de RAM y la cantidad de swap. Utilizo estos datos para determinar una media fiable y seleccionar un factor de seguridad conservador.
Parámetros importantes de un vistazo
Además de pm.max_children, otras opciones del pool determinan la limpieza con la que WordPress procesa las peticiones y lo bien que libera la memoria, lo que reduce notablemente la Estabilidad pm regula el modo: dynamic ajusta el número de procesos a la carga, static mantiene un número fijo. pm.max_requests previene el hinchamiento de memoria reiniciando los procesos después de X peticiones. request_terminate_timeout protege contra cuelgues causados por scripts defectuosos o lentos. Con este conjunto, cubro el 90 por ciento de los casos prácticos reales.
| Parámetros | Función | Recomendación de WordPress |
|---|---|---|
| pm | Modo de control del proceso | dinámico para carga variable; estático para tráfico alto permanente |
| pm.max_hijos | Número máximo de trabajadores simultáneos | RAM PHP disponible / tamaño del proceso × 0,75 |
| pm.max_requests | Reciclaje de procesos | 300-1.000; bastante menos con WooCommerce |
| request_terminate_timeout | Cancelación de solicitudes de larga duración | 60-120 segundos contra perchas |
Dinámico, a la carta o estático: ¿qué modalidad le conviene?
Selecciono el modo para que coincida con el perfil de carga: dinámico es mi opción por defecto, porque ajusta con flexibilidad el número de procesos activos y así ahorra RAM cuando hay poco en marcha. estático Lo utilizo cuando la carga es constante y necesito compromisos firmes de latencia y rendimiento, por ejemplo durante campañas o ventas. a la carta es adecuado para servidores con largas fases de inactividad: Los procesos sólo se crean cuando son necesarios y vuelven a cerrarse tras la inactividad. La contrapartida son los arranques en frío; la primera petición por proceso nuevo parece más lenta. Para ondemand establezco pm.process_idle_timeout limpiamente (por ejemplo, 10-20s), con dinámica mantengo iniciar_servidores, min_servidores_de_reserva y servidores_máximos_de_reserva tensa para que la piscina escale rápidamente pero no se „infle“.
Ejemplo de configuración para su piscina
En Debian/Ubuntu, el archivo de pool se encuentra normalmente en /etc/php/8.x/fpm/pool.d/www.conf, lo que me da un claro Estructura para personalizaciones. Configuro pm como dinámico, anclo un valor realista para pm.max_children y mantengo el servidor de repuesto ajustado. Establezco el reciclaje en 500 para limitar las fugas y los aumentos de RAM desde el principio. Después de cada cambio, pruebo la carga y tapo los cuellos de botella antes de seguir aumentando los valores. Para obtener información de fondo sobre los valores límite, la perspicacia en Optimizar pm.max_children.
pm = dinámico
pm.max_hijos = 15
pm.servidores_inicio = 4
pm.servidores_mínimos = 4
pm.max_servidores_servicio = 8
pm.max_requests = 500
request_terminate_timeout = 90s
Piscinas múltiples, enchufes y aislamiento limpio
Para proyectos múltiples o roles claramente separados (frontend vs. admin/REST), configuro piscinas separadas con su propio usuario y socket. De esta forma, cada pool limita sus propios hijos y un outlier no bloquea al resto. En un host prefiero Enchufes Unix en comparación con TCP (listen = /run/php/site.sock) - menor latencia, menos sobrecarga. Yo uso TCP entre Nginx/Apache y PHP-FPM en diferentes hosts/contenedores. Yo uso listen.owner, listen.group y modoescuchar coherente y, si es necesario, elevar lista.atraso para que los picos de carga breves no provoquen errores de conexión. Con un grupo de administradores dedicado, puedo lograr una request_terminate_timeout conducir y pm.max_requests más bajo sin ralentizar el pool de frontend con caché.
Reconocer los síntomas y reaccionar correctamente
Si el registro de errores indica regularmente „el servidor ha alcanzado pm.max_children“, el pool está limitando los Paralelismo y lo aumento moderadamente. Si ocurren 502/504 con alta utilización de swap al mismo tiempo, reinicio pm.max_children y bajo pm.max_requests. Si la CPU aumenta con baja utilización de RAM, entonces las consultas o la lógica PHP suelen bloquearse; optimizo la base de datos y la caché. Si las peticiones se atascan, un request_terminate_timeout más estricto y el análisis de registros con marcas de tiempo ayudan. Compruebo los picos conspicuos con cronjobs, índices de búsqueda y acciones de administración.
Estado del FPM y slowlog: diagnóstico preciso
Activo el Estado por pool (pm.status_path) y leer ratios como procesos activos, máximo de niños alcanzados, cola de escucha y cola de escucha máxima off. Una cola de lista en crecimiento permanente muestra claramente: muy pocos hijos o backends bloqueantes. También he configurado request_slowlog_timeout (por ejemplo, 3-5s) y un slowlog-ruta. Así es como veo los rastros de pila de las peticiones que se están demorando - a menudo llamadas HTTP externas, consultas complejas de WooCommerce o manipulaciones de imágenes. Con captura_salida_trabajadores Las advertencias de los trabajadores se recogen en los logs. Basándome en estos datos, decido si más paralelismo ayuda o si necesito resolver cuellos de botella en el código/DB.
Seguimiento: 3-5 días de evaluación limpia
Tras la puesta a punto, observo picos de carga durante varios días, porque a corto plazo fluctuaciones engañar. Registro RAM, swap, 502/504, TTFB y el número de procesos activos en el estado FPM. Por debajo del 80 por ciento de utilización de RAM sin swap y sin colas, estoy en lo cierto. Si se producen cuellos de botella durante acciones como checkout, search o imports, ajusto específicamente pm.max_children y pm.max_requests. Cada paso se realiza en pequeños ajustes y con una nueva medición.
Cálculo detallado de la memoria: RSS, PSS y memoria compartida
La variable de proceso es delicada: RSS (Resident Set Size) también contiene segmentos compartidos como OPcache y bibliotecas. Por lo tanto, sobreestimo rápidamente el consumo de RAM si calculo simplemente „RSS × Hijos“. Mejor es el PSS-view (Proportional Set Size), que distribuye equitativamente la memoria compartida entre los procesos -herramientas como smem ayudan aquí-. El cálculo incluye OPcache (por ejemplo, 256 MB + cadenas), APCu (por ejemplo, 64-128 MB) y el proceso maestro. El PHP límite_de_memoria no es una media, sino el límite superior por petición; pueden producirse picos individuales, pero el valor medio cuenta. Planifico un buffer para que los picos, despliegues y cronjobs no activen inmediatamente los swaps, y dejo pm.max_requests para limitar la sobrecarga de memoria.
Reducir la carga específica de WordPress
Primero reduzco la carga de PHP, antes de aumentar la de los niños, porque una tasa de acierto de caché más rápida ahorra tiempo real. RAM. Las cachés de página completa reducen drásticamente las peticiones PHP, lo que crea capacidad para el checkout, la búsqueda y el admin. OPcache con memory_consumption de 256 MB acelera el bytecode y alivia el pool. En la práctica, mantengo el memory_limit de PHP en 256M para que los plugins individuales no ralenticen el servidor. Puede encontrar más información sobre los cuellos de botella en la guía PHP Worker como cuello de botella.
Equilibrio entre la base de datos y la caché
Cada PHP worker genera potencialmente un Conexión a la base de datos. Si aumento pm.max_children, la carga simultánea de la BD también aumenta. Por lo tanto, compruebo MySQL/MariaDB: max_conexiones, (innodb_buffer_pool_size), y el planificador de consultas. Redis/Memcached debe mantenerse en paralelo - clientes máximos, límite de memoria y latencias. Una instancia de WordPress con 20 hijos activos puede saturar fácilmente la BD si se ejecutan varias consultas caras en paralelo. Por eso yo tuneo la BD (índices, consultas lentas) y pongo a Cachés de objetos persistentes, antes de liberar más niños. Esto aumenta el rendimiento sin sobrecargar el backend.
WooCommerce, Cron y Admin: casos especiales
Las tiendas generan más solicitudes dinámicas simultáneas, por lo que utilizo algo Aire con pm.max_children. Al mismo tiempo, tiendo a bajar pm.max_requests para reducir continuamente la sobrecarga de memoria. Para las importaciones y cronjobs, planifico presupuesto adicional o ejecuto tareas fuera de las horas punta. El área de administración suele sufrir picos a corto plazo; el almacenamiento en caché ofrece menos protección aquí, por lo que un control eficiente del pool cuenta. Si hay indicios de colas, aumento en pequeños pasos y controlo las métricas inmediatamente después.
Contenedores, cuotas de vCPU y trampas OOM
En los contenedores y las máquinas virtuales, la atención se centra en el eficaz Límite de RAM (cgroups), no en el host. Por lo tanto, calculo pm.max_children a partir del límite asignado y no a partir de „free -h“. Los OOMs de los contenedores son despiadados - el kernel termina los procesos duramente. Las cuotas de CPU también cuentan: Más hijos no ayudan si 1-2 vCPUs limitan el tiempo de computación. Como regla general, yo escalo las cargas de trabajo IO-pesadas de WordPress a alrededor de 2-4× el número de vCPUs; por encima de esto, los cambios de contexto aumentan, pero no el rendimiento real. En entornos orquestados, despliego los cambios de forma conservadora, observo los reinicios de pods y mantengo sondas de disponibilidad/vigencia para que las fases cortas de calentamiento de FPM no cuenten como fallos.
Fuentes de error que a menudo se pasan por alto
Muchos problemas no tienen su origen en la piscina, sino en Plugins, que multiplican las peticiones o generan procesos largos. Las búsquedas indexadas, las reglas de rastreo incumplidas y los intervalos excesivos entre latidos aumentan la carga. Por ello, siempre compruebo primero los registros, el monitor de consultas y las cabeceras de caché. Si la carga sólo se produce con determinadas URL, lo interpreto como una indicación de cuellos de botella de plugins o plantillas. Sólo cuando estos problemas se han resuelto, sigo ampliando Children.
Comprensión de las sesiones, admin AJAX y bloqueos
WordPress/plugins funcionan en parte con Sesiones. Los bloqueos de sesión basados en archivos pueden serializar las peticiones - una sola petición lenta bloquea el resto del mismo ID de sesión. Mantengo el uso de la sesión al mínimo y compruebo si las ráfagas de AJAX del administrador (wp-admin/admin-ajax.php) se disparan innecesariamente con frecuencia. El latido del corazón debe ser estrangulado con sensatez, de lo contrario genera carga sin valor añadido. Si se producen bloqueos o largos accesos a archivos, más paralelismo no ayudará; el almacenamiento en caché, una E/S de almacenamiento más rápida o un gestor de sesiones diferente ayudarán aquí. En los registros, reconozco estos patrones a partir de muchas peticiones similares que comienzan al mismo tiempo con tiempos de ejecución inusualmente largos.
Resumen de los tiempos de espera de Nginx, Apache y FastCGI
El servidor web también establece límites que tengo que armonizar con los valores de FPM, de lo contrario se desvanecerán. Sintonización. Con Nginx, presto atención a fastcgi_read_timeout y suficientes procesos worker. Con Apache, compruebo mpm_event, la configuración de keepalive y los tiempos de espera del proxy. Si estos límites no son correctos, los usuarios informan de timeouts aunque FPM todavía tenga capacidad. Los presupuestos de tiempo estandarizados mantienen el camino del cliente a PHP consistente.
Estrategia de despliegue, pruebas y funcionamiento
Introduzco cambios en pm.max_children paso a paso y los pruebo bajo carga real. Una recarga de FPM (graceful) asume las configuraciones sin romper la conexión. Antes de saltos mayores, simulo picos (por ejemplo, inicio de venta) y observo lo siguiente cola de escucha, CPU, RAM, percentil 95-99 de latencia e índices de error. Documento las suposiciones realizadas para que los miembros posteriores del equipo entiendan por qué se elige un valor de esta manera. Establezco alarmas para: swap > 0, „max children reached“ en el estado, aumento de 502/504 y latencia de la BD. Esto garantiza que la plataforma se mantenga estable incluso meses después, cuando cambia la mezcla de tráfico y plugins.
Brevemente resumido
Ajuste incorrecto PHP-FPM-children ralentizan WordPress, ya sea en las colas o en el límite de RAM. Determino el tamaño del proceso, reservo memoria para los servicios del sistema y establezco pm.max_children con buffer. Después compruebo pm.max_requests, request_terminate_timeout y el modo pm = dinámico o estático según el perfil de carga. Caching, OPcache y plugins limpios reducen notablemente el número de peticiones PHP. Si aplicas estos pasos de forma coherente, mantendrás la capacidad de respuesta de las páginas y la fiabilidad del servidor.
