Planificación de la capacidad de PHP-FPM: cálculo de trabajadores, RAM y solicitudes simultáneas

Qué limita un trabajador de PHP-FPM

PHP-FPM gestiona los procesos de PHP en grupos. Un Trabajador trata una solicitud cada vez; la configuración del grupo pm.max_children limita el número de trabajadores disponibles al mismo tiempo y, por lo tanto, el número de solicitudes PHP que este grupo puede procesar simultáneamente. Si hay varios grupos, el límite se aplica a cada grupo en concreto, no automáticamente a todo el servidor.

Esta cifra no corresponde ni al número de visitantes registrados ni a un valor directo de solicitudes por segundo. Un visitante puede generar varias solicitudes, mientras que un usuario registrado no ocupa un trabajador entre dos acciones. Por el contrario, una sola solicitud lenta puede mantener ocupado a un trabajador durante más tiempo que varias solicitudes cortas consecutivas.

Tampoco todas las visitas a la página llegan a PHP-FPM. Si el servidor web sirve directamente un archivo estático o si una caché previa responde a una solicitud de forma completa, no se necesita un trabajador PHP, dependiendo de la arquitectura. Por el contrario, los fallos de caché, los usuarios que han iniciado sesión y las páginas de administración pueden seguir generando solicitudes PHP y aumentar la ocupación de forma temporal.

Por lo tanto, para la planificación de la capacidad hay dos cuestiones fundamentales: ¿Cuántos «workers» caben, incluyendo una reserva, en la memoria RAM disponible? ¿Y cuántos «workers» necesita realmente el tráfico que llega al pool para que las solicitudes no tengan que esperar demasiado tiempo? Un valor elevado para pm.max_children No responde por sí sola a ninguna de estas preguntas.

Incluso si se dispone de memoria suficiente, la CPU, la base de datos o los servicios externos pueden limitar la capacidad práctica. En ese caso, aunque los trabajadores adicionales permiten realizar más tareas PHP en paralelo, también pueden aumentar la carga sobre un servicio que ya es lento. Por lo tanto, el valor del pool es un límite operativo y no una garantía de rendimiento.

Comprender los gestores de procesos y las colas

El Gestor de procesos establece cuándo PHP-FPM pone a disposición los trabajadores. En static el número de procesos reservados equivale al valor de pm.max_children. Esto permite planificar bien el número de procesos, pero también ocupa recursos incluso cuando la carga de trabajo es baja. El límite máximo debe seguir ajustándose al espacio de almacenamiento disponible.

En dynamic FPM ajusta el número de procesos: además, se configuran el número inicial y los valores mínimo y máximo de trabajadores libres. En ondemand Los «workers» solo se crean cuando es necesario y se cierran tras un tiempo de inactividad configurado. Esto puede suponer un ahorro de recursos en los grupos que se utilizan con poca frecuencia; sin embargo, en caso de un pico de carga repentino, primero hay que generar nueva capacidad de procesamiento.

Si todos los trabajadores están ocupados, las solicitudes adicionales se pueden enviar a la Cola de oyentes esperar a que se libere un proceso. El estado FPM muestra, entre otras cosas, la cola actual y la cola máxima. Sin embargo, un único valor máximo elevado no indica por sí solo si el grupo está sobrecargado en ese momento; para ello se necesita una referencia temporal.

Una cola más larga no genera trabajadores adicionales ni acelera una base de datos lenta. Puede absorber temporalmente las consultas, pero solo adelanta el tiempo de espera antes del procesamiento de PHP. Por lo tanto, a la hora de decidir qué gestor de procesos utilizar, son importantes tanto la evolución típica de la carga como las consecuencias de los picos breves.

Clasificar correctamente la memoria de los trabajadores

El consumo de memoria de un worker no se puede determinar de forma fiable basándose únicamente en un límite de configuración de PHP. Para la planificación, resultan más útiles los datos de los procesos en condiciones de carga adecuadas. En este sentido, hay que tener en cuenta si se analiza la memoria residente de un único proceso o si se quiere estimar el consumo de todo un grupo de workers de PHP-FPM.

RSS describe la memoria residente de un proceso. Si varios trabajadores utilizan las mismas páginas de memoria, estas pueden estar incluidas en sus respectivas RSS. Si se suman los valores de RSS de todos los trabajadores, las páginas compartidas pueden aparecer varias veces; por lo tanto, la suma no ofrece una imagen clara de la memoria física compartida.

PSS distribuye las páginas compartidas proporcionalmente entre los procesos implicados. Por lo tanto, la suma de los valores PSS de un grupo de procesos suele ser más útil para planificar su memoria que la suma de los valores RSS. No obstante, sigue siendo una instantánea: si cambia el número de procesos que comparten páginas, también cambian las proporciones respectivas.

Analiza el comportamiento de varios trabajadores tanto en solicitudes típicas como en aquellas que consumen mucha memoria. Un proceso recién iniciado o una media aislada pueden subestimar las necesidades posteriores. El PSS total del grupo con diferentes números de trabajadores y estados de carga ayuda a obtener un valor aproximado conservador; una extrapolación a un mayor número de trabajadores sigue siendo incierta debido a la variabilidad de las partes comunes y privadas.

El PHP-memory_limit No es un dato fiable sobre la memoria total del sistema operativo de un proceso FPM y no sustituye a esta observación. No debes restar por segunda vez de forma generalizada del presupuesto la memoria compartida —por ejemplo, por OPcache— si ya está incluida proporcionalmente en el PSS del pool utilizado. No obstante, hay que tener en cuenta otros servicios y una reserva.

Calcular el presupuesto de RAM y el número de trabajadores

El punto de partida es la memoria RAM realmente disponible: en un host, la memoria utilizable para los servicios; en el contenedor, el límite de memoria efectivo. De ahí hay que restar las necesidades del sistema operativo, del servidor web, de una posible base de datos local y de otros servicios. También hay que tener en cuenta otros grupos de FPM y una reserva para el consumo variable.

La parte restante es la Presupuesto para la piscina. Para obtener el valor estimado del trabajador, observa la suma PSS de los trabajadores del grupo con diferentes números de procesos y estados de carga. Ten en cuenta tanto las solicitudes típicas como los puntos finales que consumen mucha memoria. Divide la suma correspondiente entre el número de trabajadores considerado y deduce un valor aproximado prudente a partir de varias observaciones.

El siguiente cálculo es un ejemplo ilustrativo, no una medición. Los valores utilizados sirven únicamente para mostrar el proceso de cálculo; no constituyen una recomendación para una aplicación concreta. El resultado se redondea al número entero de trabajadores más cercano.

Los 25 trabajadores no garantizan una asignación segura. El PSS distribuye las páginas compartidas de forma proporcional y varía en función del número de procesos que comparten dichas páginas. Además, una combinación diferente de solicitudes puede modificar las necesidades de memoria privada; por lo tanto, la estimación debe contrastarse con el consumo total observado y el límite disponible.

Si la memoria compartida, como OPcache, ya está incluida proporcionalmente en la suma de PSS utilizada, no la deduzcas de nuevo de forma global como una partida adicional completa. No obstante, prevé una reserva para las partes de memoria que no se hayan tenido en cuenta en tu análisis. Precisamente en el caso de un límite de contenedores, lo que cuenta en última instancia es el consumo de todos los procesos dentro de ese límite, no solo la suma estimada de trabajadores.

Un worker recién iniciado por sí solo no es un punto de referencia muy significativo: es posible que aún no haya procesado ninguna solicitud compleja. Por eso, compara varios momentos y anota qué puntos finales y cuántos trabajadores han participado en cada caso. De este modo, se puede comprobar si el valor aproximado elegido también es válido en condiciones de funcionamiento menos favorables, pero realistas.

Calcular el número de trabajadores necesarios a partir de las solicitudes

El cálculo de la RAM describe cuántos trabajadores se prevé que quepan. Por el contrario, para calcular la demanda hay que tener en cuenta cuántas solicitudes PHP llegan realmente al grupo en cuestión y cuánto tiempo ocupan a un trabajador. Como primera aproximación, se aplica la siguiente fórmula: el número medio de trabajadores ocupados simultáneamente es igual al número de solicitudes PHP por segundo multiplicado por el tiempo medio de ocupación de un trabajador en segundos.

Ejemplo ilustrativo de cálculo, no se trata de una medición: suponiendo 20 solicitudes PHP por segundo y un tiempo medio de procesamiento de 0,25 segundos, hay una media de cinco trabajadores ocupados. Se trata de una media calculada para el periodo considerado. Esto no significa ni que siempre haya exactamente cinco procesos en funcionamiento, ni que cinco sean suficientes como límite del grupo para picos de actividad breves.

Para calcular el número de solicitudes, no debes tener en cuenta todas las visitas a la página sin verificarlas. Si una caché devuelve muchas respuestas sin recurrir a PHP, esas respuestas no suponen una carga para el pool. Por el contrario, las faltas de caché, los visitantes que han iniciado sesión y los accesos de administración pueden generar, en determinados momentos, más trabajo de PHP del que cabría suponer a partir de una media calculada a lo largo de todo el día.

El Tiempo de asignación de trabajadores También incluye los tiempos de espera durante el procesamiento, por ejemplo, al acceder a una base de datos o a un servicio externo. No debe equipararse automáticamente con el tiempo de respuesta visible en el navegador. Según fastcgi_finish_request() PHP puede haber completado ya la respuesta al cliente y, aun así, seguir ejecutando tareas en el worker.

Para conseguir tiempos de espera aceptables, necesitas un margen por encima de la ocupación media. La magnitud de ese margen depende, entre otras cosas, de las fluctuaciones de carga, de los puntos finales lentos y del objetivo de tiempo de respuesta deseado. Multiplicar el número de solicitudes máximas por segundo por un percentil de latencia elevado puede servir como una evaluación prudente del escenario, pero no constituye una previsión precisa de las colas.

Por lo tanto, hay que considerar varios periodos por separado: un breve pico de actividad y un tráfico nocturno más tranquilo pueden dar lugar a la misma media diaria que un funcionamiento más uniforme, pero plantean requisitos diferentes. Si el tiempo de procesamiento aumenta debido a un backend lento, el número medio de trabajadores ocupados también crece, incluso con la misma tasa de llegadas. Por lo tanto, la demanda no es solo una característica del volumen de visitantes.

Derivar los parámetros del grupo de cuentas de la planificación

Ahora compara el límite máximo basado en la RAM con las necesidades estimadas, incluido el margen de seguridad. Si las necesidades se sitúan por debajo de ese límite, elige un valor inicial prudente para pm.max_children, que no tiene por qué agotar el presupuesto. En el ejemplo ilustrativo, 25 sería el límite teórico de RAM, pero no necesariamente la configuración adecuada; la CPU y el backend pueden llegar a sus límites antes.

Si la demanda estimada supera el límite de RAM, aumentar ese límite no resuelve el conflicto: puede provocar una sobrecarga de memoria en el host o en el contenedor. Por el contrario, un límite muy bajo puede provocar retrasos en las solicitudes. En este caso, mejora, por ejemplo, el tiempo de ejecución o el uso de la caché y comprueba si se necesitan recursos adicionales o si es necesario limitar la carga de entrada.

En dinámico Además del límite máximo, debes establecer el número inicial, así como el número mínimo y máximo de trabajadores libres. Los valores iniciales y de reserva deben ajustarse a la carga prevista y mantenerse dentro del límite máximo. Una capacidad de reserva insuficiente puede suponer una necesidad adicional de procesos de inicio en caso de una carga repentina; por el contrario, un número elevado de procesos libres de forma permanente consume recursos.

En a la carta Los workers solo se crean cuando es necesario; el tiempo de inactividad hasta su finalización se configura por separado. Esto puede resultar útil para los pools que se utilizan con poca frecuencia, pero requiere una atención especial en caso de aumentos rápidos de la carga. También en este caso, se limita pm.max_children el número de trabajadores del grupo disponibles al mismo tiempo.

Varios sitios web alojados en el mismo servidor no disponen, de forma independiente, de toda la RAM libre. Asigna sus posibles límites máximos de pool junto con el resto de servicios y la reserva. Es posible que se aplique además un límite global de procesos FPM, si se ha configurado, pero este no sustituye ni a los presupuestos individuales de los grupos ni a la comprobación de la capacidad de la CPU y de la base de datos.

Tras realizar cambios, comprueba la carga real y los tiempos de espera durante períodos de tiempo adecuados, en lugar de dar por definitivo el valor inicial. En el caso del alojamiento gestionado, es posible que no se pueda acceder directamente a los datos de proceso o a la configuración de los grupos; en ese caso, utiliza las métricas y las opciones facilitadas por el proveedor. Además, la configuración disponible depende de la versión de PHP y del entorno operativo.

Supervisar el estado del FPM y la memoria

La página de estado de FPM muestra si los trabajadores programados son suficientes bajo una carga real. Protege el punto final de estado fuera del alcance del público: puede revelar información confidencial sobre solicitudes y recursos. Un «status listener» configurado por separado puede seguir estando disponible incluso cuando el grupo principal esté saturado; comprueba su disponibilidad y configuración para tu versión de PHP y la configuración de tu servidor web.

Considera los valores como series temporales junto con el volumen de solicitudes y los tiempos de respuesta. Un valor máximo antiguo de la cola no demuestra una sobrecarga actual; del mismo modo, en el caso de los contadores, su aumento desde la última observación es más significativo que el mero valor total. Ten en cuenta los inicios o reinicios del pool, que modifican el periodo de referencia.

En un sistema Linux que disponga de la interfaz proc, puedes consultar en modo lectura los valores de memoria agregados de un trabajador FPM conocido. Sustituye PID mediante el ID real del proceso; necesitas los derechos de acceso correspondientes. Repite la observación para varios trabajadores y estados de carga, en lugar de deducir un tamaño de grupo permanente a partir de un único proceso.

cat /proc/PID/smaps_rollup

Analizar las solicitudes lentas y las colas

Una tienda puede mostrar muchos trabajadores activos, aunque la ejecución de PHP en sí misma no sea el cuello de botella original. Si hay solicitudes en espera debido a consultas lentas a la base de datos, los trabajadores permanecen ocupados mientras tanto. Si llegan más solicitudes, la cola del listener puede crecer y el tiempo de respuesta aumentar, incluso si la CPU todavía tiene capacidad disponible.

En esta situación, un límite de trabajadores más alto podría permitir que llegaran más solicitudes simultáneas a la base de datos. Esto puede provocar que el Impresión en el backend y alargar aún más los tiempos de espera. Por eso, compara la evolución temporal de la carga de FPM y de la cola de espera con la carga de la base de datos, las consultas lentas y las llamadas a servicios externos antes de aumentar el límite.

El «slowlog» de FPM ayuda a identificar las llamadas PHP prolongadas: para las solicitudes que superen un umbral configurado, FPM puede registrar un backtrace. Este muestra un punto de ejecución y no constituye un perfil completo de toda la solicitud. Los puntos recurrentes pueden compararse con la duración de la solicitud y las métricas del backend; el Guía para analizar el registro de operaciones lentas de PHP-FPM se explica en el análisis posterior.

El tiempo de espera también debe diferenciarse de la capacidad real. En nginx, se denomina fastcgi_read_timeout el intervalo permitido entre lecturas sucesivas del servidor FastCGI, no la duración total de la solicitud en general. Un valor más alto puede permitir esperas más largas, pero no crea trabajadores adicionales ni acelera la base de datos.

Límites de capacidad y próximos pasos

Si el presupuesto de RAM no es suficiente para las necesidades estimadas, un valor más alto para pm.max_children No te centres en el conflicto de objetivos: los procesos adicionales también necesitan memoria. En su lugar, comprueba si es posible reducir el número de solicitudes PHP o la duración de su ocupación de los trabajadores. La medida más adecuada dependerá de dónde se genere la carga observada.

Un caché mejor aprovechado puede interceptar las peticiones repetidas, mientras que una ejecución más rápida de PHP y los accesos a la base de datos liberan antes a los trabajadores. Las tareas en segundo plano adecuadas pueden externalizarse fuera de la ruta inmediata de la petición; sin embargo, estas tareas también requieren sus propios recursos. Una limitación de carga protege el backend en momentos de picos, pero puede provocar que las solicitudes queden en espera o sean rechazadas.

Aumentar la memoria RAM puede permitir un mayor número de trabajadores si la memoria es, de hecho, el límite determinante. Si la CPU, la base de datos o un servicio externo ya están al límite de su capacidad, también hay que tener en cuenta dicha capacidad. Por lo tanto, el simple hecho de disponer de más memoria no garantiza ni tiempos de respuesta más cortos ni un mayor rendimiento.

Si las necesidades de memoria de cada trabajador superan su tiempo de vida, puede pm.max_requests procura que se sustituyan periódicamente. Esto puede ayudar a gestionar las fugas de memoria en bibliotecas de terceros, pero no soluciona la causa del problema. Tras realizar un cambio, sigue supervisando la memoria del pool y el comportamiento de las solicitudes, en lugar de utilizar el mecanismo de reinicio como sustituto de la depuración.

Para una decisión arquitectónica más amplia, el Comparación entre NGINX Unit y PHP-FPM Contexto: NGINX Unit está archivado y ya no se mantiene. Independientemente de la arquitectura elegida, deberías realizar los cambios basándote en series temporales Comprobar: compara, con un volumen de solicitudes similar, la cola, la carga de los trabajadores, la memoria y los tiempos de respuesta. De este modo, se puede determinar si un ajuste ha resuelto realmente el cuello de botella o si simplemente lo ha desplazado.