Configuración PHP-FPM: use pm static para o máximo rendemento

Unha versión sen editar deste artigo publicouse orixinalmente en haydenjames.io e publicado aquí co seu permiso autor.

Vouche dicir en poucas palabras a mellor forma de configurar PHP-FPM para aumentar o rendemento, reducir a latencia e utilizar a CPU e a memoria de forma máis consistente. Por defecto, a liña PM (xestor de procesos) en PHP-FPM é dinámico, e se non tes memoria suficiente, é mellor instalalo baixo demanda. Imos comparar 2 opcións de control baseadas na documentación de php.net e ver como o meu favorito difiere delas estático pm para tráfico de gran volume:

pm = dinámica — o número de procesos fillos configúrase dinámicamente en función das seguintes directivas: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = a petición - Os procesos créanse baixo demanda (a diferenza da creación dinámica, cando se inician pm.start_servers cando se inicia o servizo).
pm = estático — o número de procesos fillos está fixado e indícase polo parámetro pm.max_nenos.

Para máis detalles, consulte lista completa de directivas globais php-fpm.conf.

Semellanzas entre o xestor de procesos PHP-FPM e o controlador de frecuencia da CPU

Isto pode parecer fóra do tema, pero vou ligar isto ao tema da configuración PHP-FPM. Quen non experimentou unha desaceleración do procesador polo menos unha vez: nun portátil, máquina virtual ou servidor dedicado? Lembras a escala de frecuencia da CPU? Estas opcións están dispoñibles para nix e Windows poden mellorar o rendemento e a capacidade de resposta do sistema cambiando a configuración do acelerador do procesador baixo demanda en rendemento*. Nesta ocasión, comparemos as descricións e vexamos as semellanzas:

gobernador=a demanda — Escalado dinámico da frecuencia do procesador en función da carga actual. Salta rapidamente á frecuencia máxima e despois redúcea a medida que aumentan os períodos de inactividade.
gobernador=conservador= escala de frecuencia dinámica en función da carga actual. Aumenta e diminúe a frecuencia máis suavemente que a demanda.
Gobernador = rendemento - A frecuencia é sempre máxima.

Para máis detalles, consulte lista completa dos parámetros do regulador de frecuencia do procesador.

Ve as semellanzas? Quería mostrar esta comparación para convencerte de que é mellor usala pm estático para PHP-FPM.

Para o parámetro regulador do procesador actuación axuda a aumentar o rendemento de forma segura porque depende case enteiramente do límite de CPU do servidor. Ademais disto, por suposto, tamén hai factores como a temperatura, a carga da batería (nun portátil) e outros efectos secundarios de executar constantemente o procesador ao 100%. A configuración de rendemento garante o rendemento máis rápido do procesador. Ler, por exemplo, sobre parámetro force_turbo en Raspberry Pico que o panel RPi utilizará o regulador actuación, onde a mellora do rendemento será máis notable debido á baixa velocidade do reloxo da CPU.

Usando pm static para conseguir o máximo rendemento do servidor

Opción PHP-FPM pm estático depende en gran medida da memoria libre do servidor. Se a memoria é pouca, é mellor escoller baixo demanda ou dinámico. Por outra banda, se tes memoria, podes evitar a sobrecarga do xestor de procesos PHP configurando pm estático á máxima capacidade do servidor. Noutras palabras, se todo está ben calculado, cómpre establecer pm.estático ao máximo volume de procesos PHP-FPM que se poden executar, sen crear problemas con pouca memoria ou caché. Pero non tan alto que desborda os procesadores e acumula un montón de operacións PHP-FPM á espera de ser executadas.

Na captura de pantalla anterior, o servidor ten pm = estático e pm.max_children = 100, e isto ocupa aproximadamente 10 GB dos 32 dispoñibles. Preste atención ás columnas resaltadas, aquí está todo claro. Nesta captura de pantalla había aproximadamente 200 usuarios activos (máis de 60 segundos) en Google Analytics. Neste nivel, aproximadamente o 70% dos procesos fillos PHP-FPM aínda están inactivos. Isto significa que PHP-FPM está sempre configurado na cantidade máxima de recursos do servidor independentemente do tráfico actual. Un proceso inactivo agarda polos picos de tráfico e responde ao instante. Non tes que esperar ata pm creará procesos fillos e, a continuación, finalizará cando expire o período pm.process_idle_timeout. Definei o valor moi alto pm.max_requestsporque este é un servidor que funciona sen fugas de memoria en PHP. Podes instalar pm.max_requests = 0 con estática se confía completamente nos scripts PHP existentes e futuros. Pero é mellor volver executar os guións co tempo. Establece un gran número de solicitudes, porque queremos evitar custos de pm innecesarios. Por exemplo, polo menos pm.max_requests = 1000 - dependendo da cantidade pm.max_nenos e o número de solicitudes por segundo.

A captura de pantalla mostra o comando Linux arriba, filtrado por u (usuario) e nome de usuario PHP-FPM. Só se mostran os primeiros 50 procesos aproximadamente (non contei exactamente), pero esencialmente a parte superior mostra as principais estatísticas que caben na xanela do terminal. Neste caso ordenado por % CPU (% CPU). Para ver os 100 procesos PHP-FPM, execute o comando:

top -bn1 | grep php-fpm

Cando usar pm onde demanda e dinámico

Se usas pm dinámico, ocorren erros coma 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

Tenta cambiar o parámetro, o erro non desaparecerá, como descrito nesta publicación sobre Serverfault. Neste caso, o valor pm.min era demasiado pequeno e, dado que o tráfico web cambia moito e ten picos altos e vales profundos, é difícil axustar adecuadamente o pm. dinámico. Normalmente úsase pm baixo demanda, como se aconsella no mesmo post. Pero isto é aínda peor, porque baixo demanda termina os procesos inactivos a cero cando hai pouco ou ningún tráfico, e aínda así terás a sobrecarga de cambiar o tráfico. A menos que, por suposto, estableza un tempo de espera enorme. E entón é mellor usalo pm.estático + número alto pm.max_requests.

PM dinámico e especialmente baixo demanda pode ser útil se tes varios grupos PHP-FPM. Por exemplo, aloxa varias contas de cPanel ou varios sitios web en diferentes grupos. Teño un servidor con, por exemplo, máis de 100 contas cpanel e uns 200 dominios, e pm.static ou mesmo dynamic non me salvarían. Todo o que necesitas aquí é baixo demanda, despois de todo, máis de dous terzos dos sitios web reciben pouco ou ningún tráfico, e con baixo demanda todos os procesos fillos caerán, o que nos aforrará moita memoria! Afortunadamente, os desenvolvedores de cPanel notaron isto e estableceron o valor predeterminado baixo demanda. Anteriormente, cando o predeterminado era dinámico, PHP-FPM non era adecuado para servidores compartidos ocupados. Moitos usaron suPHP, porque pm dinámico memoria consumida incluso con grupos inactivos e contas PHP-FPM de cPanel. O máis probable é que, se o tráfico é bo, non estarás aloxado nun servidor cunha gran cantidade de pools PHP-FPM (aloxamento compartido).

Conclusión

Se está a usar PHP-FPM e o seu tráfico é pesado, xestores de procesos baixo demanda и dinámico para PHP-FPM terá un rendemento limitado debido á súa sobrecarga inherente. Comprenda o seu sistema e configure os procesos PHP-FPM segundo a capacidade máxima do servidor. Primeiro conxunto pm.max_nenos dependendo do uso máximo de pm dinámico ou baixo demanda, e despois aumente este valor ata un nivel no que a memoria e o procesador funcionen sen sobrecargarse. Notarás que con pm estático, xa que tes todo na memoria, os picos de tráfico provocarán menos picos de CPU co paso do tempo, e as medias de carga do servidor e da CPU se nivelarán. O tamaño medio do proceso PHP-FPM depende do servidor web e require unha configuración manual, polo que hai xestores de procesos máis automatizados. dinámico и baixo demanda - máis popular. Espero que o artigo fose útil.

DUP Engadido gráfico de referencia ab. Se os procesos PHP-FPM están na memoria, o rendemento aumenta a costa do consumo de memoria onde se sentan e esperan. Busca a mellor opción para ti.

Fonte: www.habr.com