🥇Nastavitev PHP-FPM: uporabite pm static za maksimalno zmogljivost

Neposredna verzija članka prvotno je objavljena na haydenjames.io i ovdje se objavljuje uz njezinu dozvolu avtorja.

Ukratko ću objasniti kako najbolje konfigurirati PHP-FPM za povećanje propusnosti, smanjenje kašnjenja i stabilnije korištenje procesorskih resursa i memorije. Zadano, postavka PM (menadžer procesa) u PHP-FPM ima vrijednost dynamic, a ako imate nedovoljno memorije, onda je bolje postaviti ondemand. Usporedimo 2 opcije upravljanja temeljem dokumentacije php.net i pogledajmo čime se razlikuje moja omiljena static pm za visok promet:

pm = dynamic — broj podprocesa se dinamički prilagođava na temelju sljedećih direktiva: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — procesi se stvaraju po potrebi (za razliku od dinamičkog stvaranja, kada se pm.start_servers pokreću prilikom pokretanja usluge).
pm = static — broj podprocesa je fiksiran i određuje se parametrom pm.max_children.

Pogledajte detalje u potpunom popisu globalnih direktiva php-fpm.conf.

Sličnosti menadžera procesa PHP-FPM s regulatorom frekvencije procesora

Možda to zvuči kao digresija, ali planiram povezati to s temom podešavanja PHP-FPM. Tko se ikad nije suočio s usporavanjem procesora – na prijenosnom računalu, virtualnom stroju ili posvećenom serveru. Sjećate se skaliranja frekvencije procesora? Ovi parametri, dostupni za nix i Windows, mogu poboljšati performanse i brzinu reakcije sustava kada promijenite postavku regulatora procesora s ondemand na performance*. Ovaj put usporedimo opise i pogledajmo sličnosti:

Governor = ondemand — dinamičko skaliranje frekvencije procesora ovisno o trenutnom opterećenju. Naglo prelazi na maksimalnu frekvenciju, a zatim je smanjuje kada se povećaju razdoblja mirovanja.
Governor = conservative = dinamičko skaliranje frekvencije ovisno o trenutnom opterećenju. Povećava i smanjuje frekvenciju glađe nego ondemand.
Governor = performance — frekvencija je uvijek maksimalna.

Pogledajte detalje u potpunom popisu parametara regulatora frekvencije procesora.

Vidite sličnosti? Htio sam pokazati ovu usporedbu kako bih vas uvjerio da je najbolje koristiti pm static za PHP-FPM.

Za regulator procesora, parametar performance pomaga varno povečati zmogljivost, saj je skoraj v celoti odvisna od procesorskega limita strežnika. Poleg tega seveda obstajajo tudi drugi dejavniki, kot so temperatura, napolnjenost baterije (v prenosniku) in drugi stranski učinki nenehne obremenitve procesorja na 100%. Nastavitev performance zagotavlja najhitrejše delovanje procesorja. Preberite, na primer, o parametru force_turbo v Raspberry Pi, s katerim bo RPi plošča uporabljala regulator performance, kjer bo izboljšanje zmogljivosti opaznejše zaradi nizke delovne frekvence CPU.

Uporaba pm static za dosego maksimalne zmogljivosti strežnika

Parameter PHP-FPM pm static je v veliki meri odvisen od prostega spomina na strežniku. Če je spomina malo, je bolje izbrati ondemand ili dynamic. Po drugi strani, če imate spomin, lahko preprečite nepotrebne stroške upravitelja procesa PHP, tako da nastavite pm static na največjo kapaciteto strežnika. Z drugimi besedami, če vse dobro preštejete, je treba nastaviti pm.static na največjo količino procesov PHP-FPM, ki jih je mogoče izvesti, brez težav s pomanjkanjem pomnilnika ali predpomnilnika. Toda ne tako visoko, da bi preobremenili procesorje in ustvarili kup operacij PHP-FPM, ki čakajo na izvedbo.

Na zgornjem posnetku zaslona je strežnik nastavljen na pm = static in pm.max_children = 100, kar vzame približno 10 GB od razpoložljivih 32. Oglejte si označene stolpce, vse je jasno. Na tem posnetku zaslona je bilo približno 200 aktivnih uporabnikov (več kot 60 sekund) v Google Analytics. Na tej ravni je približno 70 % podrejenih procesov PHP-FPM še vedno neaktivnih. To pomeni, da je PHP-FPM vedno nastavljen na največjo količino virov strežnika ne glede na trenutni promet. Neaktivni proces čaka na vrhunce prometa in takoj reagira. Ni vam treba čakati, da pm ustvari podrejene procese, nato pa jih konča, ko poteče obdobje pm.process_idle_timeout. Nastavil sem zelo visoko vrednost za pm.max_requests, ker je to delovni strežnik brez puščanja pomnilnika v PHP. Lahko nastavite pm.max_requests = 0 z static, če ste popolnoma prepričani v obstoječe in prihodnje PHP skripte. Toda bolje je, da skripte ponovno zaženete s časom. Nastavite visoko število zahtevkov, saj želimo preprečiti nepotrebne stroške pm. Na primer, vsaj pm.max_requests = 1000 — odvisno od števila pm.max_children in števila zahtevkov na sekundo.

Na posnetku zaslona je prikazana ukazna vrstica Linux top, filtrirana po u (user) in imenu uporabnika PHP-FPM. Prikazanih je le prvih 50 ali tam nekje procesov (natančno nisem štet), vendar pa top prikazuje osnovne statistike, ki se prikažejo v terminalnem oknu. V tem primeru je razvrščeno po % CPU (%CPU). Če želite videti vseh 100 procesov PHP-FPM, uporabite ukaz:

top -bn1 | grep php-fpm

Kdaj uporabiti pm ondemand in dynamic

Če uporabite pm dynamic, se pojavijo podobne napake:

WARNING: [pool xxxx] se zdi zaseden (morda boste morali povečati pm.start_servers, ali pm.min/max_spare_servers), ustvarjanje 32 otrok, 4 so neaktivni, in 59 skupnih otrok

Poskusite spremeniti parameter, napaka ne bo izginila, kot je opisano v tem prispevku na Serverfault. V tem primeru je bila vrednost pm.min premajhna, in ker se spletni promet močno spreminja, je težko ustrezno nastaviti pm dynamic. Običajno se uporablja pm ondemand, kot svetujejo v istem prispevku. Ampak to je še slabše, saj ondemand zaključi neaktivne procese do nič, ko je prometa malo ali ga sploh ni, in na koncu se boste še vedno mučili s stroški pri spreminjanju prometa. Razen seveda, če niste nastavili dolgega časa čakanja. V tem primeru je bolje uporabiti pm.static + visoko število pm.max_requests.

PM dynamic in še posebej ondemand lahko pridejo prav, če imate več PHP-FPM bazenov. Na primer, gostite nekaj računov cPanel ali več spletnih strani v različnih bazenih. Imam strežnik, kjer imam recimo 100+ cpanel računov in približno 200 domen, in pm.static ali celo dynamic me ne bi rešila. Tukaj potrebujemo le ondemand, saj več kot dve tretjini spletnih strani dobijo malo prometa ali sploh ne, in s ondemand vsi otroški procesi propadejo, kar nam prihrani veliko pomnilnika! Na srečo so razvijalci cPanel to opazili in nastavili privzeto vrednost ondemand. Prej, ko je bila privzeta vrednost dynamic, PHP-FPM sploh ni bil primeren za obremenjene skupne strežnike. Mnogi so uporabljali suPHP, ker je pm dynamic porabljal pomnilnik tudi pri neaktivnih bazenih in računih cPanel PHP-FPM. Verjetno, pri dobrem prometu ne boste gostili na strežniku z velikim številom PHP-FPM bazenov (skupno gostovanje).

Zaključek

Če uporabljate PHP-FPM in imate resen promet, bodo upravljalci procesov ondemand in dynamic za PHP-FPM omejevali propustnost zaradi inherentnih stroškov. Preučite svoj sistem in nastavite procese PHP-FPM v skladu z maksimalno kapaciteto strežnika. Najprej nastavite pm.max_children odvisno od maksimalne uporabe pm dynamic ili ondemand, nato pa povečajte to vrednost do ravni, kjer bosta pomnilnik in procesor delovala brez pretiranega obremena. Opazili boste, da pm static, ker imate vse shranjeno v pomnilniku, bodo vrhovi prometa sčasoma povzročili manj vrhov za procesor, povprečne obremenitve strežnika in procesorja pa se bodo izravnale. Povprečna velikost procesa PHP-FPM je odvisna od spletnega strežnika in zahteva ročno prilagoditev, zato so bolj avtomatizirani upravljalci procesov – dynamic in ondemand – bolj priljubljeni. Upam, da je bil članek koristen.

UPD Dodana je bila diagram bencinske postaje ab. Če so procesi PHP-FPM v pomnilniku, se povečuje zmogljivost na račun porabe pomnilnika, kjer sedijo in čakajo. Prilagodite optimizacijo za sebe.