Postavljanje PHP-FPM-a: koristite pm static za maksimalnu izvedbu

Nelektorirana verzija ovog članka izvorno je objavljena na haydenjames.io i ovdje objavljen uz njezino dopuštenje Autor.

Ukratko ću vas provesti kroz najbolji način za konfiguriranje PHP-FPM-a za povećanje propusnosti, smanjenje kašnjenja i dosljednije korištenje CPU-a i memorije. Prema zadanim postavkama, linija PM (process manager) u PHP-FPM-u je dinamičan, a ako nemate dovoljno memorije, onda je bolje instalirati OnDemand. Usporedimo 2 opcije kontrole na temelju php.net dokumentacije i vidimo kako se moja omiljena razlikuje od njih statički pm za veliki promet:

pm = dinamički — broj procesa djece konfigurira se dinamički na temelju sljedećih direktiva: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = na zahtjev - procesi se kreiraju na zahtjev (za razliku od dinamičkog kreiranja, kada se pm.start_servers pokreću prilikom pokretanja usluge).
pm = statičan — broj podređenih procesa je fiksan i označen je parametrom pm.max_children.

Za detalje pogledajte kompletan popis globalnih direktiva php-fpm.conf.

Sličnosti između PHP-FPM upravitelja procesa i CPU frekvencijskog kontrolera

Ovo se može činiti izvan teme, ali ovo ću povezati s temom konfiguracije PHP-FPM-a. Tko nije doživio usporavanje procesora barem jednom - na prijenosnom računalu, virtualnom računalu ili namjenskom poslužitelju. Sjećate li se skaliranja frekvencije procesora? Ove su opcije dostupne za nix i Windows mogu poboljšati performanse i odziv sustava promjenom postavke gasa procesora iz OnDemand na izvođenje*. Ovaj put usporedimo opise i pogledajmo sličnosti:

namjesnik=na zahtjev — dinamičko skaliranje frekvencije procesora ovisno o trenutnom opterećenju. Brzo skače na maksimalnu frekvenciju, a zatim je smanjuje kako se razdoblja neaktivnosti povećavaju.
guverner=konzervativac= dinamičko skaliranje frekvencije ovisno o trenutnom opterećenju. Povećava i smanjuje frekvenciju glatkije nego na zahtjev.
Guverner = izvedba — frekvencija je uvijek maksimalna.

Za detalje pogledajte potpuni popis parametara regulatora frekvencije procesora.

Vidite sličnosti? Htio sam prikazati ovu usporedbu kako bih vas uvjerio da je najbolja za korištenje pm statičan za PHP-FPM.

Za parametar regulatora procesora predstava pomaže u sigurnom povećanju performansi jer gotovo u potpunosti ovisi o ograničenju procesora poslužitelja. Uz ovo, naravno, tu su i faktori kao što su temperatura, napunjenost baterije (kod laptopa) i druge nuspojave stalnog rada procesora na 100%. Postavka izvedbe osigurava najbrži rad procesora. Pročitajte, na primjer, o force_turbo parametar u Raspberry Pi, s kojim će RPi panel koristiti regulator predstava, gdje će poboljšanje performansi biti vidljivije zbog niske brzine CPU-a.

Korištenje pm static za postizanje maksimalnih performansi poslužitelja

PHP-FPM opcija pm statičan uvelike ovisi o slobodnoj memoriji na poslužitelju. Ako je memorije malo, bolje je izabrati OnDemand ili dinamičan. S druge strane, ako imate memorije, možete izbjeći opterećenje PHP upravitelja procesa postavljanjem pm statički do maksimalnog kapaciteta poslužitelja. Drugim riječima, ako je sve dobro proračunato, trebate uspostaviti pm.statički na maksimalnu količinu PHP-FPM procesa koji se mogu izvršiti, bez stvaranja problema s nedostatkom memorije ili predmemorije. Ali ne tako visok da preoptereti procesore i nakupi hrpu PHP-FPM operacija koje čekaju na izvršenje.

Na gornjoj snimci zaslona poslužitelj ima pm = statički i pm.max_children = 100, a ovo zauzima otprilike 10 GB od raspoloživih 32. Obratite pozornost na označene stupce, ovdje je sve jasno. Na ovoj snimci zaslona bilo je približno 200 aktivnih korisnika (više od 60 sekundi) u Google Analyticsu. Na ovoj razini, otprilike 70% PHP-FPM procesa djece je još uvijek u stanju mirovanja. To znači da je PHP-FPM uvijek postavljen na maksimalnu količinu resursa poslužitelja bez obzira na trenutni promet. Proces u mirovanju čeka vršne prometne gužve i odmah reagira. Ne morate čekati do pm će stvoriti podređene procese i zatim ih prekinuti kada razdoblje istekne pm.process_idle_timeout. Postavio sam vrijednost na vrlo visoku pm.max_requestsjer je ovo radni poslužitelj bez curenja memorije u PHP-u. Možete instalirati pm.max_requests = 0 sa statičkim ako ste potpuno sigurni u postojeće i buduće PHP skripte. Ali bolje je s vremenom ponovno pokrenuti skripte. Postavite veliki broj zahtjeva, jer želimo izbjeći nepotrebne pm troškove. Na primjer, barem pm.max_requests = 1000 - ovisno o količini pm.max_children i broj zahtjeva u sekundi.

Snimka zaslona prikazuje naredbu Linux vrh, filtrirano prema u (korisnik) i PHP-FPM korisničkom imenu. Prikazano je samo prvih 50-ak procesa (nisam točno brojao), ali u suštini vrh prikazuje vrhunsku statistiku koja stane u prozor terminala. U ovom slučaju sortirano po % CPU (%CPU). Da biste vidjeli svih 100 PHP-FPM procesa, pokrenite naredbu:

top -bn1 | grep php-fpm

Kada koristiti pm na zahtjev i dinamički

Ako koristite pm dinamičan, pojavljuju se ovakve pogreške:

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

Pokušajte promijeniti parametar, pogreška neće nestati, kao opisano u ovom postu na Serverfaultu. U ovom slučaju vrijednost pm.min bila je premala, a budući da se web promet toliko mijenja i ima visoke vrhove i duboke doline, teško je adekvatno prilagoditi pm dinamičan. Obično se koristi pm OnDemand, kao što je savjetovano u istom postu. Ali ovo je još gore, jer OnDemand prekida neaktivne procese na nulu kada ima malo ili nimalo prometa, a vi ćete i dalje imati režijske troškove promjene prometa. Osim ako, naravno, ne postavite veliko vrijeme čekanja. I onda je bolje koristiti pm.statički + visok broj pm.max_requests.

PM dinamičan i osobito OnDemand može dobro doći ako imate više PHP-FPM skupova. Na primjer, hostirate više cPanel računa ili više web stranica u različitim bazenima. Imam server sa recimo 100+ cpanel računa i oko 200 domena i pm.static ili čak dynamic me ne bi spasili. Sve što trebate ovdje je OnDemand, uostalom, više od dvije trećine web stranica ima malo ili nimalo prometa, a sa OnDemand svi podređeni procesi će otpasti, što će nam uštedjeti puno memorije! Srećom, programeri cPanela su to primijetili i postavili vrijednost na zadanu OnDemand. Ranije, kada je zadana vrijednost bila dinamičan, PHP-FPM uopće nije bio prikladan za zauzete dijeljene poslužitelje. Mnogi su koristili suPHP, jer pm dinamičan troši memoriju čak i s neaktivnim bazenima i cPanel PHP-FPM računima. Najvjerojatnije, ako je promet dobar, nećete biti smješteni na poslužitelju s velikim brojem PHP-FPM skupova (shared hosting).

Zaključak

Ako koristite PHP-FPM i promet vam je veliki, upravitelji procesa OnDemand и dinamičan za PHP-FPM bit će ograničena propusnost zbog inherentnih dodatnih troškova. Razumite svoj sustav i konfigurirajte PHP-FPM procese prema maksimalnom kapacitetu poslužitelja. Prvi set pm.max_children ovisno o maksimalnoj upotrebi pm dinamičan ili OnDemand, a zatim povećajte ovu vrijednost do razine na kojoj će memorija i procesor raditi bez preopterećenja. Primijetit ćete da sa pm statičan, budući da imate sve u memoriji, skokovi prometa uzrokovat će manje skokova CPU-a tijekom vremena, a prosječna opterećenja poslužitelja i CPU-a će se izjednačiti. Prosječna veličina PHP-FPM procesa ovisi o web poslužitelju i zahtijeva ručnu konfiguraciju, tako da su automatiziraniji upravitelji procesa dinamičan и OnDemand - popularniji. Nadam se da je članak bio koristan.

DUP Dodan referentni grafikon ab. Ako su PHP-FPM procesi u memoriji, performanse se povećavaju na račun potrošnje memorije gdje stoje i čekaju. Pronađite najbolju opciju za sebe.

Izvor: www.habr.com