PHP-FPM häälestus: kasutage maksimaalse jõudluse saavutamiseks pm static'i

Selle artikli muutmata versioon avaldati algselt haydenjames.io ja avaldati siin tema loal autor.

Ma ütlen teile lühidalt, kuidas PHP-FPM-i kõige paremini konfigureerida, et suurendada läbilaskevõimet, vähendada latentsust ning kasutada protsessorit ja mälu järjepidevamalt. Vaikimisi on PHP-FPM rida PM (protsessihaldur). dünaamiline, ja kui teil pole piisavalt mälu, on parem installida nõudlusel. Võrdleme kahte juhtimisvõimalust php.net dokumentatsiooni põhjal ja vaatame, kuidas minu lemmik neist erineb staatiline pm suure liikluse korral:

pm = dünaamiline — alamprotsesside arv konfigureeritakse dünaamiliselt järgmiste direktiivide alusel: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = nõudmisel - protsessid luuakse nõudmisel (erinevalt dünaamilisest loomisest, kui teenuse käivitamisel käivitatakse pm.start_servers).
pm = staatiline — alamprotsesside arv on fikseeritud ja seda näitab parameeter pm.max_lapsed.

Üksikasju vt globaalsete direktiivide täielik loetelu php-fpm.conf.

PHP-FPM protsessihalduri ja protsessori sageduskontrolleri sarnasused

See võib tunduda offtopic, kuid ma seon selle PHP-FPM konfiguratsiooni teemaga. Kes poleks vähemalt korra kogenud protsessori aeglustumist – sülearvutis, virtuaalmasinas või spetsiaalses serveris. Kas mäletate protsessori sageduse skaleerimist? Need valikud on saadaval nix ja Windows saavad parandada süsteemi jõudlust ja reageerimisvõimet, muutes protsessori gaasipedaali sätteid nõudlusel edasi jõudlus*. Seekord võrdleme kirjeldusi ja vaatame sarnasusi:

kuberner=ondemand — protsessori sageduse dünaamiline skaleerimine sõltuvalt praegusest koormusest. Hüppab kiiresti maksimaalsele sagedusele ja vähendab seda siis, kui tegevusetusperioodid suurenevad.
kuberner=konservatiiv= dünaamiline sageduse skaleerimine sõltuvalt praegusest koormusest. Suurendab ja vähendab sagedust sujuvamalt kui nõudmisel.
Kuberner = sooritus — sagedus on alati maksimaalne.

Üksikasju vt protsessori sagedusregulaatori parameetrite täielik loetelu.

Kas näete sarnasusi? Tahtsin seda võrdlust näidata, et veenda teid, et seda on kõige parem kasutada pm staatiline PHP-FPM jaoks.

Protsessori regulaatori parameetri jaoks jõudlus aitab jõudlust ohutult suurendada, kuna see sõltub peaaegu täielikult serveri CPU piirangust. Lisaks sellele on loomulikult ka sellised tegurid nagu temperatuur, aku laetus (sülearvutis) ja muud kõrvalmõjud, kui protsessor pidevalt 100% töötab. Jõudluse seadistus tagab protsessori kiireima jõudluse. Lugege näiteks umbes parameeter force_turbo rakenduses Raspberry Pi, millega RPi paneel hakkab regulaatorit kasutama jõudlus, kus jõudluse paranemine on protsessori madala taktsageduse tõttu märgatavam.

Pm static kasutamine serveri maksimaalse jõudluse saavutamiseks

PHP-FPM valik pm staatiline sõltub suuresti serveri vabast mälust. Kui mälu on vähe, on parem valida nõudlusel või dünaamiline. Teisest küljest, kui teil on mälu, saate vältida PHP protsessihalduri lisakulusid, seades pm staatiline kuni serveri maksimaalse võimsuseni. Teisisõnu, kui kõik on hästi arvutatud, peate kehtestama pm.staatiline PHP-FPM protsesside maksimaalse mahuni, mida saab käivitada, tekitamata probleeme vähese mälu või vahemäluga. Kuid mitte nii kõrge, et see protsessorid üle koormaks ja kuhjaks hunniku PHP-FPM toiminguid, mis ootavad täitmist.

Ülaltoodud ekraanipildil on serveril pm = staatiline ja pm.max_lapsed = 100, ja see võtab umbes 10 GB saadaolevast 32-st. Pöörake tähelepanu esiletõstetud veergudele, siin on kõik selge. Sellel ekraanipildil oli Google Analyticsis umbes 200 aktiivset kasutajat (üle 60 sekundi). Sellel tasemel on umbes 70% PHP-FPM alamprotsessidest endiselt jõude. See tähendab, et PHP-FPM on alati seatud maksimaalsele serveriressurssidele sõltumata praegusest liiklusest. Jõudeoleku protsess ootab liikluse tippe ja reageerib kohe. Sa ei pea ootama, kuni pm loob alamprotsessid ja lõpetab need perioodi lõppedes pm.process_idle_timeout. Seadsin väärtuse väga kõrgeks pm.max_requestssest see on töötav server, millel pole PHP-s mälulekkeid. Saate installida pm.max_requests = 0 staatilisega, kui olete olemasolevates ja tulevastes PHP skriptides täiesti kindel. Kuid parem on skripte aja jooksul uuesti käivitada. Määra suur hulk taotlusi, sest soovime vältida tarbetuid pm-kulusid. Näiteks vähemalt pm.max_requests = 1000 - sõltuvalt kogusest pm.max_lapsed ja taotluste arv sekundis.

Ekraanitõmmis näitab käsku Linuxi tipp, filtreeritakse u (kasutaja) ja PHP-FPM kasutajanime järgi. Kuvatakse vaid esimesed 50 protsessi (ma täpselt ei lugenud), aga sisuliselt top näitab terminali aknasse mahtuvat tippstatistikat. Sel juhul sorteeritakse % CPU (%CPU) järgi. Kõigi 100 PHP-FPM protsessi vaatamiseks käivitage käsk:

top -bn1 | grep php-fpm

Millal kasutada pm ondemand ja dynamic

Kui kasutad pm dünaamiline, ilmnevad sellised vead:

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

Proovige parameetrit muuta, viga ei kao, näiteks kirjeldatud selles Serverfaulti postituses. Sel juhul oli pm.min väärtus liiga väike ja kuna veebiliiklus on väga erinev ning sellel on kõrged tipud ja sügavad orud, on pm-i adekvaatne reguleerimine keeruline dünaamiline. Tavaliselt kasutatakse pm-i nõudlusel, nagu samas postituses soovitati. Kuid see on veelgi hullem, sest nõudlusel lõpetab jõudeoleku protsessid nullini, kui liiklust on vähe või üldse mitte, ja teil on ikkagi liikluse muutmine. Kui te muidugi ei määra tohutut ooteaega. Ja siis on parem kasutada pm.staatiline + kõrge number pm.max_requests.

PM dünaamiline ja eriti nõudlusel võib olla kasulik, kui teil on mitu PHP-FPM kogumit. Näiteks hostite mitut cPaneli kontot või mitut veebisaiti erinevates kogumites. Mul on server, millel on näiteks 100+ cpaneli kontot ja umbes 200 domeeni ning pm.static või isegi dynamic mind ei päästaks. Siin on kõik, mida vajate nõudlusel, on ju enam kui kahel kolmandikul veebisaitidest liiklus vähe või üldse mitte ning koos nõudlusel kõik alamprotsessid kukuvad ära, mis säästab palju mälu! Õnneks märkasid cPaneli arendajad seda ja määrasid väärtuse vaikeväärtuseks nõudlusel. Varem, kui vaikimisi oli dünaamiline, PHP-FPM ei sobinud hõivatud jagatud serveritele üldse. Paljud on kasutanud suPHP, sest pm dünaamiline tarbis mälu isegi jõudeoleku kogumite ja cPanel PHP-FPM kontode korral. Tõenäoliselt ei majutata teid hea liikluse korral serveris, kus on palju PHP-FPM-i kogumeid (jagatud hostimine).

Järeldus

Kui kasutate PHP-FPM-i ja teie liiklus on tihe, siis protsessihaldurid nõudlusel и dünaamiline PHP-FPM puhul on nende loomuliku üldkulude tõttu piiratud läbilaskevõime. Mõistke oma süsteemi ja seadistage PHP-FPM protsesse vastavalt serveri maksimaalsele võimsusele. Esimene komplekt pm.max_lapsed sõltuvalt maksimaalsest pm kasutusest dünaamiline või nõudluselja seejärel suurendage seda väärtust tasemeni, kus mälu ja protsessor töötavad ilma ülekoormamiseta. Märkad seda koos pm staatiline, kuna teil on kõik mälus, põhjustavad liikluse hüpped aja jooksul vähem CPU naelu ning serveri ja protsessori koormuse keskmised ühtlustuvad. Keskmine PHP-FPM protsessi suurus sõltub veebiserverist ja nõuab käsitsi seadistamist, seega on rohkem automatiseeritud protsessihaldureid dünaamiline и nõudlusel - populaarsem. Loodan, et artikkel oli kasulik.

DUP Lisatud võrdlusdiagramm ab. Kui PHP-FPM protsessid on mälus, suureneb jõudlus mälutarbimise arvelt, kus nad istuvad ja ootavad. Leia enda jaoks parim variant.

Allikas: www.habr.com