Una versió no editada d'aquest article es va publicar originalment a i publicat aquí amb el seu permís .
Us explicaré en poques paraules la millor manera de configurar PHP-FPM per augmentar el rendiment, reduir la latència i utilitzar la CPU i la memòria de manera més coherent. Per defecte, la línia PM (gestor de processos) a PHP-FPM és dinàmic, i si no teniu prou memòria, és millor instal·lar-lo ondemand. Comparem 2 opcions de control basades en la documentació de php.net i veiem com es diferencia el meu preferit estàtic pm per a trànsit de gran volum:
pm = dinàmic — el nombre de processos fills es configura dinàmicament en funció de les directives següents: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = a demanda - els processos es creen sota demanda (a diferència de la creació dinàmica, quan s'inicien pm.start_servers quan s'inicia el servei).
pm = estàtic — el nombre de processos fills és fix i s'indica amb el paràmetre pm.max_nens.
Per a més detalls, vegeu .
Similituds entre el gestor de processos PHP-FPM i el controlador de freqüència de la CPU
Això pot semblar fora de tema, però l'enllaçaré amb el tema de la configuració de PHP-FPM. Qui no ha experimentat una desacceleració del processador almenys una vegada: en un ordinador portàtil, màquina virtual o servidor dedicat. Recordeu l'escala de freqüència de la CPU? Aquestes opcions estan disponibles per nix i Windows poden millorar el rendiment i la capacitat de resposta del sistema canviant la configuració de l'accelerador del processador ondemand en rendiment*. Aquesta vegada, comparem les descripcions i observem les semblances:
governador=a demanda — Escalat dinàmic de la freqüència del processador en funció de la càrrega actual. Salta ràpidament a la freqüència màxima i després la redueix a mesura que augmenten els períodes d'inactivitat.
governador=conservador= escala de freqüència dinàmica en funció de la càrrega actual. Augmenta i disminueix la freqüència més suaument que a demanda.
Governador = rendiment — La freqüència és sempre màxima.
Per a més detalls, vegeu .
Veus les semblances? Volia mostrar aquesta comparació per convèncer-vos que és millor utilitzar-la pm estàtica per a PHP-FPM.
Per al paràmetre regulador del processador performance ajuda a augmentar el rendiment de manera segura perquè depèn gairebé completament del límit de CPU del servidor. A més d'això, és clar, també hi ha factors com la temperatura, la càrrega de la bateria (en un ordinador portàtil) i altres efectes secundaris d'executar constantment el processador al 100%. La configuració de rendiment garanteix el rendiment més ràpid del processador. Llegeix, per exemple, sobre , amb el qual el panell RPi utilitzarà el regulador performance, on la millora del rendiment serà més notable a causa de la baixa velocitat de rellotge de la CPU.
Utilitzant pm static per aconseguir el màxim rendiment del servidor
Opció PHP-FPM pm estàtica depèn en gran mesura de la memòria lliure del servidor. Si la memòria és baixa, és millor triar ondemand o dinàmic. D'altra banda, si teniu memòria, podeu evitar la sobrecàrrega del gestor de processos PHP configurant pm estàtic a la capacitat màxima del servidor. En altres paraules, si tot està ben calculat, cal establir pm.estàtica al volum màxim de processos PHP-FPM que es poden executar, sense crear problemes amb poca memòria o memòria cau. Però no tan alt que aclapara els processadors i acumula un munt d'operacions PHP-FPM a l'espera de ser executades.
A la captura de pantalla anterior, el servidor té pm = estàtica i pm.max_children = 100, i això ocupa aproximadament 10 GB dels 32 disponibles. Pareu atenció a les columnes destacades, aquí tot queda clar. En aquesta captura de pantalla hi havia aproximadament 200 usuaris actius (més de 60 segons) a Google Analytics. En aquest nivell, aproximadament el 70% dels processos fills PHP-FPM encara estan inactius. Això significa que PHP-FPM sempre s'estableix a la quantitat màxima de recursos del servidor, independentment del trànsit actual. Un procés inactiu espera els pics de trànsit i respon a l'instant. No cal esperar fins pm crearà processos fills i després els finalitzarà quan expiri el període pm.process_idle_timeout. Vaig posar el valor a molt alt pm.max_requestsperquè aquest és un servidor que funciona sense fuites de memòria en PHP. Podeu instal·lar pm.max_requests = 0 amb estàtica si confieu completament en els scripts PHP existents i futurs. Però és millor reiniciar els scripts amb el temps. Establiu un gran nombre de peticions, perquè volem evitar costos de pm innecessaris. Per exemple, almenys pm.max_requests = 1000 - depenent de la quantitat pm.max_nens i el nombre de peticions per segon.
La captura de pantalla mostra l'ordre , filtrat per u (usuari) i nom d'usuari PHP-FPM. Només es mostren els primers 50 processos més o menys (no vaig comptar exactament), però essencialment la part superior mostra les estadístiques principals que encaixen a la finestra del terminal. En aquest cas ordenat per % CPU (%CPU). Per veure els 100 processos PHP-FPM, executeu l'ordre:
top -bn1 | grep php-fpmQuan utilitzar pm a demanda i dinàmic
Si utilitzeu pm dinàmic, es produeixen errors com aquest:
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 childrenProveu de canviar el paràmetre, l'error no desapareixerà, com ara . En aquest cas, el valor pm.min era massa petit, i com que el trànsit web canvia molt i té pics elevats i valls profundes, és difícil ajustar adequadament el pm dinàmic. Normalment s'utilitza pm ondemand, . Però això és encara pitjor, perquè ondemand finalitza els processos inactius a zero quan hi ha poc o cap trànsit, i encara acabareu amb la sobrecàrrega del trànsit canviant. A menys, per descomptat, establiu un gran temps d'espera. I llavors és millor utilitzar pm.estàtica + nombre alt pm.max_requests.
PM dinàmic i especialment ondemand pot ser útil si teniu diversos grups PHP-FPM. Per exemple, allotgeu diversos comptes de cPanel o diversos llocs web en grups diferents. Tinc un servidor amb, per exemple, més de 100 comptes de cpanel i uns 200 dominis, i pm.static o fins i tot dynamic no em salvaria. Tot el que necessites aquí és ondemand, al cap i a la fi, més de dos terços dels llocs web reben poc o cap trànsit, i amb ondemand tots els processos secundaris cauran, cosa que ens estalviarà molta memòria! Afortunadament, els desenvolupadors de cPanel ho van adonar i van establir el valor per defecte ondemand. Anteriorment, quan era el valor predeterminat dinàmic, PHP-FPM no era adequat per a servidors compartits ocupats. Molts han utilitzat suPHP, perquè pm dinàmic memòria consumida fins i tot amb grups inactius i comptes PHP-FPM de cPanel. Molt probablement, si el trànsit és bo, no estareu allotjats en un servidor amb un gran nombre de grups PHP-FPM (allotjament compartit).
Conclusió
Si utilitzeu PHP-FPM i el vostre trànsit és intens, gestors de processos ondemand и dinàmic per a PHP-FPM tindrà un rendiment limitat a causa de la seva sobrecàrrega inherent. Comprèn el teu sistema i configura els processos PHP-FPM segons la capacitat màxima del servidor. Primer conjunt pm.max_nens depenent de l'ús màxim de la tarda dinàmic o ondemand, i després augmenta aquest valor fins a un nivell on la memòria i el processador funcionin sense sobrecarregar-se. Ho notareu amb pm estàtica, com que ho teniu tot a la memòria, els pics de trànsit provocaran menys pics de CPU amb el pas del temps i les mitjanes de càrrega del servidor i de la CPU s'anivellaran. La mida mitjana del procés PHP-FPM depèn del servidor web i requereix una configuració manual, de manera que els gestors de processos són més automatitzats. dinàmic и ondemand - més popular. Espero que l'article hagi estat útil.
UPD S'ha afegit un gràfic de referència . Si els processos PHP-FPM es troben a la memòria, el rendiment augmenta a costa del consum de memòria on s'asseuen i esperen. Trobeu la millor opció per a vosaltres mateixos.
Font: www.habr.com