Nastavitev PHP-FPM: uporabite pm static za največjo zmogljivost

Nelektorirana različica tega članka je bila prvotno objavljena na haydenjames.io in z njenim dovoljenjem objavljen tukaj avtor.

Na kratko vam bom povedal, kako najbolje konfigurirati PHP-FPM, da povečate prepustnost, zmanjšate zakasnitev in dosledneje uporabljate CPE in pomnilnik. Privzeto je vrstica PM (upravitelj procesov) v PHP-FPM dinamično, in če nimate dovolj pomnilnika, potem je bolje namestiti ondemand. Primerjajmo 2 možnosti nadzora na podlagi dokumentacije php.net in poglejmo, v čem se moja najljubša razlikuje od njiju statična pm za velik promet:

pm = dinamično — število podrejenih procesov je dinamično konfigurirano na podlagi naslednjih direktiv: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = na zahtevo - procesi se ustvarjajo na zahtevo (v nasprotju z dinamičnim ustvarjanjem, ko se pm.start_servers zaženejo ob zagonu storitve).
pm = statično — število podrejenih procesov je fiksno in je označeno s parametrom pm.max_children.

Za podrobnosti glejte celoten seznam globalnih direktiv php-fpm.conf.

Podobnosti med upravljalnikom procesov PHP-FPM in frekvenčnim krmilnikom CPU

Morda se zdi, da ni tema, vendar bom to povezal s temo konfiguracije PHP-FPM. Kdo se še ni vsaj enkrat srečal z upočasnitvijo procesorja - na prenosniku, virtualnem stroju ali namenskem strežniku. Se spomnite skaliranja frekvence procesorja? Te možnosti so na voljo za nix in Windows lahko izboljšata delovanje in odzivnost sistema s spremembo nastavitve dušilca ​​procesorja iz ondemand o izvedba*. Tokrat primerjajmo opise in poglejmo podobnosti:

guverner=ondemand — dinamično skaliranje frekvence procesorja glede na trenutno obremenitev. Hitro skoči na največjo frekvenco in jo nato zmanjša, ko se obdobja nedejavnosti povečajo.
guverner=konservativec= dinamično skaliranje frekvence glede na trenutno obremenitev. Poveča in zmanjša frekvenco bolj gladko kot na zahtevo.
Guverner = uspešnost — frekvenca je vedno največja.

Za podrobnosti glejte celoten seznam parametrov frekvenčnega regulatorja procesorja.

Vidite podobnosti? To primerjavo sem želel pokazati, da bi vas prepričal, da je najboljša za uporabo pm statičen za PHP-FPM.

Za parameter regulatorja procesorja performance pomaga varno povečati zmogljivost, ker je skoraj v celoti odvisna od omejitve procesorja strežnika. Poleg tega so seveda tu še dejavniki, kot so temperatura, napolnjenost baterije (pri prenosniku) in drugi stranski učinki nenehnega delovanja procesorja na 100%. Nastavitev zmogljivosti zagotavlja najhitrejše delovanje procesorja. Preberite na primer o parameter force_turbo v Raspberry Pi, s katerim bo RPi panel uporabljal regulator performance, kjer bo izboljšanje zmogljivosti bolj opazno zaradi nizkega takta procesorja.

Uporaba pm static za doseganje največje zmogljivosti strežnika

Možnost PHP-FPM pm statičen v veliki meri odvisno od prostega pomnilnika na strežniku. Če je pomnilnika malo, je bolje izbrati ondemand ali dinamično. Po drugi strani pa se lahko, če imate pomnilnik, izognete obremenitvi upravitelja procesov PHP tako, da nastavite pm statična do največje zmogljivosti strežnika. Z drugimi besedami, če je vse dobro izračunano, morate vzpostaviti popoldan.statično na največjo količino procesov PHP-FPM, ki jih je mogoče izvesti, brez ustvarjanja težav s pomanjkanjem pomnilnika ali predpomnilnika. Vendar ne tako visoko, da bi preobremenilo procesorje in nakopičilo kup operacij PHP-FPM, ki čakajo na izvedbo.

Na zgornjem posnetku zaslona ima strežnik pm = statičen in pm.max_children = 100, kar zavzame približno 10 GB od razpoložljivih 32. Bodite pozorni na označene stolpce, tukaj je vse jasno. Na tem posnetku zaslona je bilo približno 200 aktivnih uporabnikov (več kot 60 sekund) v storitvi Google Analytics. Na tej ravni je približno 70 % podrejenih procesov PHP-FPM še vedno nedejavnih. To pomeni, da je PHP-FPM vedno nastavljen na največjo količino strežniških virov, ne glede na trenutni promet. Nedejaven proces čaka na konice prometa in se takoj odzove. Ni vam treba čakati do pm bo ustvaril podrejene procese in jih nato zaključil, ko poteče obdobje pm.process_idle_timeout. Vrednost sem nastavil na zelo visoko pm.max_requestsker je to delujoč strežnik brez puščanja pomnilnika v PHP. Lahko namestite pm.max_requests = 0 s statično, če ste popolnoma prepričani v obstoječe in prihodnje skripte PHP. Vendar je bolje sčasoma znova zagnati skripte. Postavite veliko število zahtev, saj se želimo izogniti nepotrebnim pm stroškom. Na primer, vsaj pm.max_requests = 1000 - odvisno od količine pm.max_children in število zahtev na sekundo.

Posnetek zaslona prikazuje ukaz Linux vrh, filtrirano po u (uporabnik) in uporabniškem imenu PHP-FPM. Prikazanih je samo prvih 50 ali več procesov (nisem natančno štel), vendar v bistvu vrh prikazuje najvišjo statistiko, ki se prilega oknu terminala. V tem primeru razvrščeno po % CPU (% CPU). Za ogled vseh 100 procesov PHP-FPM zaženite ukaz:

top -bn1 | grep php-fpm

Kdaj uporabiti pm na zahtevo in dinamično

Če uporabljate pm dinamično, pride do takšnih napak:

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

Poskusite spremeniti parameter, napaka ne bo izginila, npr opisano v tej objavi na Serverfault. V tem primeru je bila vrednost pm.min premajhna in ker se spletni promet zelo spreminja in ima visoke vrhove in globoke doline, je težko ustrezno prilagoditi pm dinamično. Ponavadi se uporablja pm ondemand, kot svetujejo v isti objavi. A to je še hujše, saj ondemand prekine nedejavne procese na nič, ko je prometa malo ali ga sploh ni, pa boste še vedno imeli režijske stroške spreminjanja prometa. Razen seveda, če si nastavite ogromno čakalno dobo. In potem je bolje uporabiti popoldan.statično + visoka številka pm.max_requests.

PM dinamično in zlasti ondemand lahko pride prav, če imate več skupin PHP-FPM. Na primer, gostite več računov cPanel ali več spletnih mest v različnih skupinah. Imam strežnik z recimo 100+ cpanel računi in okoli 200 domenami in pm.static ali celo dynamic me ne bi rešila. Vse kar potrebujete tukaj je ondemand, navsezadnje več kot dve tretjini spletnih strani prejme malo ali nič prometa in s ondemand vsi podrejeni procesi bodo odpadli, kar nam bo prihranilo veliko spomina! Na srečo so razvijalci cPanela to opazili in nastavili vrednost na privzeto ondemand. Prej, ko je bila privzeta dinamično, PHP-FPM sploh ni bil primeren za zasedene skupne strežnike. Mnogi so uporabljali suPHP, ker pm dinamično porabil pomnilnik tudi z nedejavnimi bazeni in računi cPanel PHP-FPM. Najverjetneje, če je promet dober, ne boste gostovali na strežniku z velikim številom PHP-FPM bazenov (deljeno gostovanje).

Zaključek

Če uporabljate PHP-FPM in je vaš promet velik, upravitelji procesov ondemand и dinamično za PHP-FPM bo imela omejena prepustnost zaradi njihovih inherentnih stroškov. Razumejte svoj sistem in konfigurirajte procese PHP-FPM glede na največjo zmogljivost strežnika. Prvi set pm.max_children odvisno od maksimalne porabe pm dinamično ali ondemandin nato povečajte to vrednost na raven, ko bosta pomnilnik in procesor delovala brez preobremenitve. Opazili boste, da s pm statičen, ker imate vse v pomnilniku, bodo skoki prometa sčasoma povzročili manj skokov CPE, povprečna obremenitev strežnika in CPE pa se bo izravnala. Povprečna velikost procesa PHP-FPM je odvisna od spletnega strežnika in zahteva ročno konfiguracijo, zato so bolj avtomatizirani upravitelji procesov dinamično и ondemand - bolj priljubljena. Upam, da je bil članek koristen.

DUP Dodan primerjalni grafikon ab. Če so procesi PHP-FPM v pomnilniku, se zmogljivost poveča na račun porabe pomnilnika, kjer sedijo in čakajo. Poiščite najboljšo možnost zase.

Vir: www.habr.com