PHP-FPM podešavanje: koristite pm static za maksimalne performanse

Neuređena verzija ovog članka prvobitno je objavljena na haydenjames.io i objavljena ovdje uz njenu dozvolu autor.

Reći ću vam ukratko kako najbolje da konfigurišete PHP-FPM za povećanje propusnosti, smanjenje kašnjenja i konzistentnije korišćenje CPU-a i memorije. Podrazumevano, PM (proces manager) linija u PHP-FPM je Dinamičan, a ako nemate dovoljno memorije, onda je bolje instalirati na zahtjev. Hajde da uporedimo 2 kontrolne opcije na osnovu php.net dokumentacije i vidimo po čemu se moj favorit razlikuje od njih statički popodne za veliki saobraćaj:

pm = dinamički — broj podređenih procesa se dinamički konfiguriše na osnovu 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 kada se servis pokrene).
pm = statički — broj podređenih procesa je fiksan i označen je parametrom pm.max_children.

Za detalje pogledajte kompletna lista globalnih direktiva php-fpm.conf.

Sličnosti između PHP-FPM menadžera procesa i CPU kontrolera frekvencije

Ovo može izgledati offtopic, ali ja ću ovo povezati sa temom PHP-FPM konfiguracije. Ko nije barem jednom iskusio usporavanje procesora - na laptopu, virtuelnoj mašini ili namenskom serveru. Zapamtite skaliranje frekvencije procesora? Ove opcije su dostupne za nix i Windows mogu poboljšati performanse sistema i odziv promjenom podešavanja gasa procesora sa na zahtjev na performanse*. Ovaj put, uporedimo opise i pogledajmo sličnosti:

guverner=zahtjev — dinamičko skaliranje frekvencije procesora u zavisnosti od trenutnog opterećenja. Brzo skače na maksimalnu frekvenciju, a zatim je smanjuje kako se periodi neaktivnosti povećavaju.
guverner=konzervativac= dinamičko skaliranje frekvencije ovisno o trenutnom opterećenju. Povećava i smanjuje frekvenciju lakše nego na zahtjev.
Guverner = učinak — frekvencija je uvijek maksimalna.

Za detalje pogledajte potpuna lista parametara regulatora frekvencije procesora.

Vidite sličnosti? Htio sam pokazati ovo poređenje kako bih vas uvjerio da je najbolje koristiti pm static za PHP-FPM.

Za parametar regulatora procesora performanse pomaže sigurnom povećanju performansi jer gotovo u potpunosti ovisi o ograničenju CPU servera. Pored ovoga, naravno, tu su i faktori kao što su temperatura, napunjenost baterije (u laptopu) i druge nuspojave stalnog rada procesora na 100%. Postavka performansi osigurava najbrže performanse procesora. Pročitajte, na primjer, o parametar force_turbo u Raspberry Pi, sa kojim će RPi panel koristiti regulator performanse, gdje će poboljšanje performansi biti primjetnije zbog niske brzine procesorskog takta.

Korišćenje pm static za postizanje maksimalnih performansi servera

PHP-FPM opcija pm static u velikoj mjeri zavisi od slobodne memorije na serveru. Ako je memorija slaba, bolje je izabrati na zahtjev ili Dinamičan. S druge strane, ako imate memoriju, možete izbjeći opterećenje PHP menadžera procesa postavljanjem pm statički do maksimalnog kapaciteta servera. Drugim riječima, ako je sve dobro izračunato, potrebno je utvrditi pm.static do maksimalnog obima PHP-FPM procesa koji se mogu izvršiti, bez stvaranja problema sa malo memorije ili keša. Ali ne tako visoko da preopterećuje procesore i akumulira gomilu PHP-FPM operacija koje čekaju da se izvrše.

Na slici iznad, server ima pm = statički i pm.max_children = 100, a ovo zauzima otprilike 10 GB od raspoloživih 32. Obratite pažnju na označene kolone, ovdje je sve jasno. Na ovom snimku ekrana bilo je približno 200 aktivnih korisnika (više od 60 sekundi) u Google Analytics. Na ovom nivou, otprilike 70% PHP-FPM podređenih procesa je i dalje neaktivno. To znači da je PHP-FPM uvijek postavljen na maksimalnu količinu resursa servera bez obzira na trenutni promet. Proces u mirovanju čeka vrhunce prometa i odmah reagira. Ne morate čekati do pm će kreirati podređene procese, a zatim ih prekinuti kada period istekne pm.process_idle_timeout. Postavio sam vrijednost na vrlo visoku pm.max_requestsjer je ovo server koji radi 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 ponovo pokrenuti skripte s vremenom. Postavite veliki broj zahtjeva, jer želimo izbjeći nepotrebne pm troškove. Na primjer, barem pm.max_requests = 1000 - zavisno od količine pm.max_children i broj zahtjeva u sekundi.

Snimak ekrana prikazuje komandu Linux top, filtrirano po u (korisnik) i PHP-FPM korisničkim imenom. Prikazano je samo prvih 50-ak procesa (nisam tačno izbrojao), ali u suštini top prikazuje top statistiku koja se uklapa u prozor terminala. U ovom slučaju sortirano po % CPU (%CPU). Da vidite svih 100 PHP-FPM procesa, pokrenite naredbu:

top -bn1 | grep php-fpm

Kada koristiti pm ondemand i dynamic

Ako koristite pm Dinamičan, javljaju se greške poput ove:

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, greška neće nestati, npr opisano u ovom postu na Serverfault. U ovom slučaju, pm.min vrijednost je bila premala, a budući da web promet toliko varira i ima visoke vrhove i duboke doline, teško je adekvatno prilagoditi pm Dinamičan. Obično se koristi pm na zahtjev, kako je savjetovano u istom postu. Ali ovo je još gore, jer na zahtjev prekida neaktivne procese na nulu kada ima malo ili nimalo saobraćaja, a vi ćete i dalje imati troškove promjene prometa. Osim ako, naravno, ne postavite veliko vrijeme čekanja. I tada je bolje koristiti pm.static + veliki broj pm.max_requests.

PM Dinamičan i posebno na zahtjev može biti od koristi ako imate više PHP-FPM bazena. Na primjer, hostujete više cPanel naloga ili više web stranica u različitim grupama. Imam server sa, recimo, 100+ cpanel naloga i oko 200 domena, a pm.static ili čak dinamički me ne bi spasili. Sve što vam treba ovde je na zahtjev, na kraju krajeva, više od dvije trećine web stranica prima malo ili nimalo prometa, i to sa na zahtjev svi podređeni procesi će pasti, što će nam uštedjeti mnogo memorije! Na sreću, cPanel programeri su to primijetili i postavili vrijednost na default na zahtjev. Ranije, kada je zadana vrijednost bila Dinamičan, PHP-FPM uopšte nije bio pogodan za zauzete deljene servere. Mnogi su koristili suPHP, jer pm Dinamičan troši memoriju čak i sa neaktivnim skupovima i cPanel PHP-FPM nalozima. Najvjerovatnije, ako je promet dobar, nećete biti hostovani na serveru sa velikim brojem PHP-FPM pulova (dijeljeni hosting).

zaključak

Ako koristite PHP-FPM i vaš promet je velik, menadžeri procesa na zahtjev и Dinamičan za PHP-FPM će biti ograničena propusnost zbog inherentnih troškova. Razumite svoj sistem i konfigurišite PHP-FPM procese prema maksimalnom kapacitetu servera. Prvi set pm.max_children ovisno o maksimalnoj upotrebi pm Dinamičan ili na zahtjev, a zatim povećajte ovu vrijednost na nivo na kojem će memorija i procesor raditi bez preopterećenja. To ćete primijetiti sa pm static, budući da imate sve u memoriji, nagli promet će uzrokovati manje skokova CPU-a tokom vremena, a prosjeci opterećenja servera i CPU-a će se izjednačiti. Prosječna veličina PHP-FPM procesa ovisi o web serveru i zahtijeva ručnu konfiguraciju, pa su više automatizirani menadžeri procesa Dinamičan и na zahtjev - popularniji. Nadam se da je članak bio koristan.

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

izvor: www.habr.com