Configuración de PHP-FPM: use pm static para obtener el máximo rendimiento

Una versión sin editar de este artículo se publicó originalmente en haydenjames.io y publicado aquí con su permiso автора.

Le diré en pocas palabras cuál es la mejor manera de configurar PHP-FPM para aumentar el rendimiento, reducir la latencia y utilizar la CPU y la memoria de manera más consistente. De forma predeterminada, la línea PM (administrador de procesos) en PHP-FPM es lugar de trabajo dinámico, y si no tienes suficiente memoria, entonces es mejor instalar Bajo demanda. Comparemos 2 opciones de control basadas en la documentación de php.net y veamos en qué se diferencia mi favorita de ellas. estático pm para tráfico de alto volumen:

pm = dinámico — el número de procesos secundarios se configura dinámicamente en función de las siguientes directivas: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = bajo demanda - los procesos se crean bajo demanda (a diferencia de la creación dinámica, cuando se inicia pm.start_servers cuando se inicia el servicio).
pm = estática — el número de procesos secundarios es fijo y se indica mediante el parámetro pm.max_children.

Para más detalles, consulte lista completa de directivas globales php-fpm.conf.

Similitudes entre el administrador de procesos PHP-FPM y el controlador de frecuencia de la CPU

Esto puede parecer fuera de tema, pero lo vincularé al tema de la configuración de PHP-FPM. ¿Quién no ha experimentado al menos una vez una ralentización del procesador de un portátil, una máquina virtual o un servidor dedicado? ¿Recuerdas el escalado de frecuencia de la CPU? Estas opciones están disponibles para nix y Windows pueden mejorar el rendimiento y la capacidad de respuesta del sistema cambiando la configuración del acelerador del procesador de Bajo demanda en actuación*. Esta vez, comparemos las descripciones y veamos las similitudes:

gobernador = bajo demanda — escalado dinámico de la frecuencia del procesador dependiendo de la carga actual. Salta rápidamente a la frecuencia máxima y luego la reduce a medida que aumentan los períodos de inactividad.
gobernador=conservador= Escalado dinámico de frecuencia dependiendo de la carga actual. Aumenta y disminuye la frecuencia más suavemente que bajo demanda.
Gobernador = desempeño — la frecuencia es siempre máxima.

Para más detalles, consulte lista completa de parámetros del regulador de frecuencia del procesador.

¿Ves las similitudes? Quería mostrar esta comparación para convencerte de que es mejor usar pm estática para PHP-FPM.

Para el parámetro del regulador del procesador actuación ayuda a aumentar el rendimiento de forma segura porque depende casi por completo del límite de CPU del servidor. Además de esto, por supuesto, también existen factores como la temperatura, la carga de la batería (en una computadora portátil) y otros efectos secundarios de ejecutar constantemente el procesador al 100%. La configuración de rendimiento garantiza el rendimiento más rápido del procesador. Lea, por ejemplo, sobre Parámetro force_turbo en Raspberry Pi, con el que el panel RPi utilizará el regulador actuación, donde la mejora del rendimiento será más notoria debido a la baja velocidad del reloj de la CPU.

Uso de pm static para lograr el máximo rendimiento del servidor

Opción PHP-FPM pm estática Depende en gran medida de la memoria libre en el servidor. Si la memoria es poca, es mejor elegir. Bajo demanda o lugar de trabajo dinámico. Por otro lado, si tiene memoria, puede evitar la sobrecarga del administrador de procesos PHP configurando pm estático hasta la capacidad máxima del servidor. En otras palabras, si todo está bien calculado, es necesario establecer pm.estático al volumen máximo de procesos PHP-FPM que se pueden ejecutar, sin crear problemas con poca memoria o caché. Pero no tan alto como para abrumar a los procesadores y acumular un montón de operaciones PHP-FPM esperando ser ejecutadas..

En la captura de pantalla anterior, el servidor tiene pm = estático y pm.max_children = 100, y esto ocupa aproximadamente 10 GB de los 32 disponibles. Presta atención a las columnas resaltadas, aquí todo está claro. En esta captura de pantalla había aproximadamente 200 usuarios activos (más de 60 segundos) en Google Analytics. En este nivel, aproximadamente el 70% de los procesos secundarios de PHP-FPM todavía están inactivos. Esto significa que PHP-FPM siempre está configurado con la cantidad máxima de recursos del servidor, independientemente del tráfico actual. Un proceso inactivo espera picos de tráfico y responde instantáneamente. No tienes que esperar hasta pm creará procesos secundarios y luego los finalizará cuando expire el período pm.process_idle_timeout. Puse el valor en muy alto pm.max_requestsporque este es un servidor que funciona sin pérdidas de memoria en PHP. puedes instalar pm.max_requests = 0 con estática si tiene plena confianza en los scripts PHP existentes y futuros. Pero es mejor volver a ejecutar los scripts con el tiempo. Establezca una gran cantidad de solicitudes, porque queremos evitar costos de pm innecesarios. Por ejemplo, al menos pm.max_requests = 1000 - dependiendo de la cantidad pm.max_children y el número de solicitudes por segundo.

La captura de pantalla muestra el comando. Linux arriba, filtrado por u (usuario) y nombre de usuario PHP-FPM. Solo se muestran los primeros 50 procesos aproximadamente (no los conté exactamente), pero esencialmente top muestra las estadísticas principales que caben en la ventana del terminal. En este caso ordenados por % CPU (%CPU). Para ver los 100 procesos PHP-FPM, ejecute el comando:

top -bn1 | grep php-fpm

Cuándo utilizar pm ondemand y dinámico

Si usas pm lugar de trabajo dinámico, se producen errores como este:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Intente cambiar el parámetro, el error no desaparecerá, como descrito en esta publicación en Serverfault. En este caso, el valor pm.min era demasiado pequeño y, dado que el tráfico web varía mucho y tiene picos altos y valles profundos, es difícil ajustar adecuadamente pm. lugar de trabajo dinámico. Generalmente se usa pm Bajo demanda, como se aconseja en el mismo post. Pero esto es aún peor, porque Bajo demanda finaliza los procesos inactivos a cero cuando hay poco o ningún tráfico, y aún terminará con la sobrecarga del tráfico cambiante. A menos, por supuesto, que establezcas un tiempo de espera enorme. Y entonces es mejor usar pm.estático + numero alto pm.max_requests.

PM lugar de trabajo dinámico y especialmente Bajo demanda Puede resultar útil si tiene varios grupos PHP-FPM. Por ejemplo, aloja varias cuentas de cPanel o varios sitios web en diferentes grupos. Tengo un servidor con, digamos, más de 100 cuentas de cpanel y alrededor de 200 dominios, y pm.static o incluso dinámico no me salvarían. Todo lo que necesitas aquí es Bajo demandaDespués de todo, más de dos tercios de los sitios web reciben poco o ningún tráfico, y con Bajo demanda ¡Todos los procesos secundarios desaparecerán, lo que nos ahorrará mucha memoria! Afortunadamente, los desarrolladores de cPanel notaron esto y establecieron el valor predeterminado. Bajo demanda. Anteriormente, cuando el valor predeterminado era lugar de trabajo dinámico, PHP-FPM no era adecuado en absoluto para servidores compartidos ocupados. Muchos han usado PHP, porque pm lugar de trabajo dinámico consumió memoria incluso con grupos inactivos y cuentas cPanel PHP-FPM. Lo más probable es que, si el tráfico es bueno, no esté alojado en un servidor con una gran cantidad de grupos PHP-FPM (alojamiento compartido).

Conclusión

Si está utilizando PHP-FPM y su tráfico es intenso, los administradores de procesos Bajo demanda и lugar de trabajo dinámico para PHP-FPM tendrá un rendimiento limitado debido a su sobrecarga inherente. Comprenda su sistema y configure procesos PHP-FPM de acuerdo con la capacidad máxima del servidor. Primer set pm.max_children dependiendo del uso máximo de pm lugar de trabajo dinámico o Bajo demanday luego aumente este valor a un nivel en el que la memoria y el procesador funcionen sin sobrecargarse. Notarás que con pm estática, dado que tiene todo en la memoria, los picos de tráfico provocarán menos picos de CPU con el tiempo y los promedios de carga del servidor y de la CPU se nivelarán. El tamaño promedio del proceso PHP-FPM depende del servidor web y requiere configuración manual, por lo que se necesitan administradores de procesos más automatizados. lugar de trabajo dinámico и Bajo demanda - más popular. Espero que el artículo haya sido útil.

UPD Gráfico de referencia agregado ab. Si los procesos PHP-FPM están en la memoria, el rendimiento aumenta a expensas del consumo de memoria donde permanecen y esperan. Encuentra la mejor opción para ti.

Fuente: habr.com