Configurare PHP-FPM: utilizați pm static pentru performanță maximă

O versiune needitată a acestui articol a fost publicată inițial pe haydenjames.io și publicat aici cu permisiunea ei autor.

Vă voi spune pe scurt cum să configurați cel mai bine PHP-FPM pentru a crește debitul, a reduce latența și a utiliza CPU și memoria mai constant. În mod implicit, linia PM (manager de proces) în PHP-FPM este dinamic, iar dacă nu aveți suficientă memorie, atunci este mai bine să instalați la cerere. Să comparăm 2 opțiuni de control bazate pe documentația php.net și să vedem cum diferă preferatul meu de ele static pm pentru trafic de volum mare:

pm = dinamic — numărul de procese copil este configurat dinamic pe baza următoarelor directive: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = la cerere - procesele sunt create la cerere (spre deosebire de crearea dinamică, când pm.start_servers sunt lansate la pornirea serviciului).
pm = static — numărul de procese copil este fix și este indicat de parametru pm.max_copii.

Pentru detalii, vezi lista completă a directivelor globale php-fpm.conf.

Asemănări între managerul de proces PHP-FPM și controlerul de frecvență al procesorului

Acest lucru poate părea offtopic, dar voi face legătura cu subiectul configurației PHP-FPM. Cine nu a experimentat o încetinire a procesorului cel puțin o dată - pe un laptop, mașină virtuală sau server dedicat? Vă amintiți scalarea frecvenței CPU? Aceste opțiuni sunt disponibile pentru nix și Windows pot îmbunătăți performanța și capacitatea de răspuns a sistemului schimbând setarea accelerației procesorului de la la cerere pe performanţă*. De data aceasta, să comparăm descrierile și să vedem asemănările:

guvernator=la cerere — scalarea dinamică a frecvenței procesorului în funcție de sarcina curentă. Trece rapid la frecvența maximă și apoi o reduce pe măsură ce perioadele de inactivitate cresc.
guvernator=conservator= scalarea dinamică a frecvenței în funcție de sarcina curentă. Crește și scade frecvența mai ușor decât la cerere.
Guvernator = performanta — frecvența este întotdeauna maximă.

Pentru detalii, vezi lista completă a parametrilor regulatorului de frecvență a procesorului.

Vezi asemănările? Am vrut să arăt această comparație pentru a vă convinge că cel mai bine este să folosiți pm static pentru PHP-FPM.

Pentru parametrul regulator procesorului performanță ajută la creșterea în siguranță a performanței, deoarece depinde aproape în întregime de limita CPU a serverului. Pe lângă aceasta, desigur, există și factori precum temperatura, încărcarea bateriei (într-un laptop) și alte efecte secundare ale rulării constant a procesorului la 100%. Setarea de performanță asigură cea mai rapidă performanță a procesorului. Citiți, de exemplu, despre parametrul force_turbo în Raspberry Pi, cu care panoul RPi va folosi regulatorul performanță, unde îmbunătățirea performanței va fi mai vizibilă datorită vitezei scăzute de ceas a procesorului.

Utilizarea pm static pentru a obține performanța maximă a serverului

Opțiunea PHP-FPM pm static depinde în mare măsură de memoria liberă de pe server. Dacă memoria este scăzută, este mai bine să alegeți la cerere sau dinamic. Pe de altă parte, dacă aveți memorie, puteți evita overhead-ul managerului de proces PHP setând pm static la capacitatea maximă a serverului. Cu alte cuvinte, dacă totul este bine calculat, trebuie să stabiliți pm.static la volumul maxim de procese PHP-FPM care pot fi executate, fără a crea probleme cu memoria sau memoria cache scăzută. Dar nu atât de mare încât să copleșească procesoarele și să acumuleze o grămadă de operațiuni PHP-FPM care așteaptă să fie executate.

În captura de ecran de mai sus, serverul are pm = static și pm.max_children = 100, iar asta ocupă aproximativ 10 GB din cei 32 disponibili. Atenție la coloanele evidențiate, totul este clar aici. În această captură de ecran au existat aproximativ 200 de utilizatori activi (mai mult de 60 de secunde) în Google Analytics. La acest nivel, aproximativ 70% din procesele copil PHP-FPM sunt încă inactive. Aceasta înseamnă că PHP-FPM este întotdeauna setat la cantitatea maximă de resurse de server, indiferent de traficul curent. Un proces inactiv așteaptă vârfurile de trafic și răspunde instantaneu. Nu trebuie să așteptați până pm va crea procese copil și apoi le va încheia când expiră perioada pm.process_idle_timeout. Am setat valoarea la foarte mare pm.max_requestsdeoarece acesta este un server care funcționează fără scurgeri de memorie în PHP. Puteți instala pm.max_requests = 0 cu static dacă sunteți complet încrezător în scripturile PHP existente și viitoare. Dar este mai bine să rulați din nou scripturile în timp. Setați un număr mare de solicitări, pentru că dorim să evităm costurile inutile cu PM. De exemplu, cel puțin pm.max_requests = 1000 - in functie de cantitate pm.max_copii și numărul de solicitări pe secundă.

Captura de ecran arată comanda Linux de sus, filtrat după u (utilizator) și numele de utilizator PHP-FPM. Sunt afișate doar primele 50 de procese (nu am numărat exact), dar în esență top arată statisticile de top care se potrivesc în fereastra terminalului. În acest caz sortat după % CPU (%CPU). Pentru a vedea toate cele 100 de procese PHP-FPM, rulați comanda:

top -bn1 | grep php-fpm

Când să utilizați pm la cerere și dinamic

Dacă folosești pm dinamic, apar erori de genul acesta:

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

Încercați să schimbați parametrul, eroarea nu va dispărea, de exemplu descris în această postare pe Serverfault. În acest caz, valoarea pm.min a fost prea mică și, deoarece traficul web variază atât de mult și are vârfuri înalte și văi adânci, este dificil să ajustați în mod adecvat pm dinamic. De obicei se folosește pm la cerere, asa cum se recomanda in aceeasi postare. Dar acest lucru este și mai rău, pentru că la cerere termină procesele inactive la zero atunci când traficul este puțin sau deloc și veți ajunge în continuare cu suprasarcina de modificare a traficului. Cu excepția cazului în care, desigur, stabiliți un timp de așteptare uriaș. Și atunci este mai bine să folosești pm.static + număr mare pm.max_requests.

PM dinamic și mai ales la cerere poate fi util dacă aveți mai multe pool-uri PHP-FPM. De exemplu, găzduiți mai multe conturi cPanel sau mai multe site-uri web în grupuri diferite. Am un server cu, să zicem, peste 100 de conturi cpanel și aproximativ 200 de domenii, iar pm.static sau chiar dynamic nu m-ar salva. Tot ce ai nevoie aici este la cerere, la urma urmei, mai mult de două treimi din site-uri web primesc trafic redus sau deloc, și cu la cerere toate procesele copil vor cădea, ceea ce ne va economisi multă memorie! Din fericire, dezvoltatorii cPanel au observat acest lucru și au stabilit valoarea implicită la cerere. Anterior, când implicit era dinamic, PHP-FPM nu era deloc potrivit pentru serverele partajate ocupate. Mulți au folosit suPHP, pentru că pm dinamic memorie consumată chiar și cu pool-uri inactive și conturi cPanel PHP-FPM. Cel mai probabil, dacă traficul este bun, nu vei fi găzduit pe un server cu un număr mare de pool-uri PHP-FPM (shared hosting).

Concluzie

Dacă utilizați PHP-FPM și traficul dvs. este intens, managerii de proces la cerere и dinamic pentru PHP-FPM va fi debit limitat din cauza supraîncărcării lor inerente. Înțelegeți-vă sistemul și configurați procesele PHP-FPM în funcție de capacitatea maximă a serverului. Primul set pm.max_copii în funcție de utilizarea maximă a pm dinamic sau la cerere, apoi creșteți această valoare la un nivel în care memoria și procesorul vor funcționa fără a fi supraîncărcate. Vei observa asta cu pm static, deoarece aveți totul în memorie, vârfurile de trafic vor cauza mai puține creșteri ale procesorului în timp, iar mediile de încărcare a serverului și procesorului se vor nivela. Dimensiunea medie a procesului PHP-FPM depinde de serverul web și necesită configurare manuală, astfel încât managerii de procese mai automatizați sunt dinamic и la cerere - mai popular. Sper că articolul a fost util.

DUP Adăugat grafic de referință ab. Dacă procesele PHP-FPM sunt în memorie, performanța crește în detrimentul consumului de memorie acolo unde stau și așteaptă. Găsiți cea mai bună opțiune pentru dvs.

Sursa: www.habr.com