PHP-FPM seadistamine: kasutame pm static maksimaalse jõudluse saavutamiseks.

Muudatamata artikli versioon avaldati algselt saidil haydenjames.io ja avaldatakse siin tema autori.

Küsin lühidalt, kuidas seadistada PHP-FPM, et suurendada läbilaskevõimet, vähendada latentsust ning stabiilsemalt kasutada protsessoriressursse ja mälu. Vaikimisi on PHP-FPM-i protsessihalduri rida dünaamiline, ja kui mälu on vähe, on parem seadistada nõudmisel. Vaatame kahte haldamisvõimalust php.net dokumentatsiooni põhjal ja võrrelgeme, kuidas need erinevad minu lemmikust staatiline süsteemist suure liikluse korral:

pm = dünaamiline — alamsüsteemide arv kohandatakse dünaamiliselt järgmiste direktiivide põhjal: 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 pm.start_servers käivitatakse teenuse käivitamisel).
pm = staatiline — alamsüsteemide arv on fikseeritud ja määratakse parameetriga pm.max_children.

Üksikasju leiate täielikku nimekirja globaalsetest direktiividest php-fpm.conf.

PHP-FPM protsessi halduri sarnasused protsessori sageduse regulaatoriga

See võib tunduda offtopic, kuid kavatsen selle siduda PHP-FPM seadistamise teemaga. Kas keegi pole kunagi kogenud protsessori pidurdumist — olgu see sülearvutis, virtuaalmasinas või pühendatud serveris? Kas mäletate protsessori sageduse skaalamist? Need seadistused, mis on saadaval nii nixis kui ka Windowsis, võivad suurendada süsteemi jõudlust ja reageerimiskiirus, kui muuta protsessoriregulaatori parameeter nõudmisel järgnevaga performance*. Seekord võrreldakse kirjeldusi ja uuritakse sarnasusi:

Governor = ondemand — protsessori sageduse dünaamiline skaalamine sõltuvalt praegusest koormusest. Tõuseb järsult maksimaalsele sagedusele, seejärel väheneb, kui vabad perioodid suurenevad.
Governor = conservative = dünaamiline sageduse skaalamine sõltuvalt praegusest koormusest. Suurendab ja vähendab sagedust sujuvamalt kui ondemand.
Governor = performance — sagedus on alati maksimaalne.

Üksikasju leiate täielik loetelu protsessoriregulaatori parameetritest.

Kas näete sarnasust? Soovisin näidata seda võrdlust, et veenda teid, et parim valik on pm static PHP-FPM jaoks.

Protsessoriregulaatori parameeter performance aitab aitab turvaliselt suurendada jõudlust, kuna see sõltub peaaegu täielikult serveri protsessori piirangust. Loomulikult on veel faktoreid, nagu temperatuur, aku laadimine (sülearvutis) ja muud kõrvaltoimed, mis tulenevad protsessori pidevast töötamisest 100% koormusel. Jõudluse seadistamine tagab protsessori kiireima töö. Loe näiteks Raspberry Pi force_turbo parameetrist, millega RPi paneel kasutab regulaatorit performance, kus jõudluse paranemine on märgatavam madala CPU taktsageduse tõttu.

pm static kasutamine maksimaalse serveri jõudluse saavutamiseks

PHP-FPM parameeter pm static sõltub suuresti serveri vaba mälust. Kui mälu on vähe, oleks parem valida nõudmisel või dünaamiline. Teisest küljest, kui teil on mälu, saate vältida PHP protsessihalduri liigset kulu, seadistades pm staatiline serveri maksimaalsele mahule. Teisisõnu, kui kõik on hästi kokku arvestatud, tuleb seadistada pm.static PHP-FPM maksimaalsete protsesside mahule, mis võivad töötada, mäluprobleemide või vahemälu puudumise tõttu. Kuid mitte liiga kõrgele, et CPUsid üle koormata ja kuhjata suurt hulka PHP-FPM operatsioone, mis ootavad täitmist..

Ülaltoodud ekraanipildil on serveril seadistatud pm = static ja pm.max_children = 100., ja see võtab umbes 10 GB olemasolevast 32 GB-st. Pange tähele esile toodud veerge, siin on kõik selge. Sel ekraanipildil oli umbes 200 aktiivset kasutajat (üle 60 sekundi) Google Analytics's. Selle taseme juures on umbes 70% PHP-FPM alamprotsessidest endiselt passiivsed. See tähendab, et PHP-FPM on alati seadistatud serveri maksimaalsete ressursside kasutamiseks, sõltumata praegusest liiklusest. Passiivne protsess ootab liikluse tippusid ja reageerib hetkega. Te ei pea ootama, kuni pm loob alamprotsessid ja siis lõpetab need, kui aeg on läbi. pm.process_idle_timeout. Ma seadistasin sellele väga suure väärtuse pm.max_requests, sest see on töötav server, kus ei esine PHP mälu leket. Võite seada pm.max_requests = 0. Kasutage static, kui olete täiesti kindel olemasolevates ja tulevastes PHP skriptides. Kuid parem on skripte aeg-ajalt taaskäivitada. Seadke suur küsimuste arv, et vältida liigseid kulutusi pm. Näiteks vähemalt pm.max_requests = 1000 — sõltuvalt arvust pm.max_children ja sekundis tehtud päringute arvust.

Kü screenshotil on näidatud käsk Linux top, filtreeritud u (kasutaja) ja PHP-FPM kasutajanime järgi. Näidatud on ainult esimesed 50 protsessi (täpselt ei lugenud), kuid põhimõtteliselt näitab top statistikat, mis mahub terminali aknasse. Sel juhul on sorteerimine % CPU (%CPU) järgi. Kõik 100 PHP-FPM protsessi vaatamiseks käivitage käsk:

top -bn1 | grep php-fpm

Millal kasutada pm ondemand ja dynamic

Kui kasutada pm dünaamiline, siis tekivad sellised vead:

WARNING: [pool xxxx] näib olevat hõivatud (võite vajada pm.start_servers või pm.min/max_spare_servers suurendamist), genereerides 32 last, ja 4 on ootel, kokku 59 last

Proovige parameetrit muuta, viga ei kao kuhugi, nagu on kirjeldatud selles Serverfault postituses. Sel juhul oli pm.min väärtus liiga väike, ning kuna veebiliiklus muutub tugevalt ja tal on suured tipud ja sügavad langused, on keeruline pm adekvaatselt seadistada. dünaamiline. Tavaliselt kasutatakse pm nõudmisel, nagu soovitatakse samas postituses. Aga see on veel hullem, sest nõudmisel lõpetab tegevusetud protsessid nulli, kui liiklust on vähe või ei ole üldse, ja lõppkokkuvõttes pead sa ikka kannatama kulude all liikluse muutumise korral. Kui just ei ole seadnud tohutut ooteaega. Ja siis on parem kasutada pm.static + kõrge arv pm.max_requests.

PM dünaamiline ja eriti nõudmisel võivad osutuda kasulikeks, kui sul on mitu PHP-FPM basseini. Näiteks, kui majutad mitu cPaneli kontot või mitu veebisaiti erinevates basseinides. Mul on server, kus on ütleme 100+ cPaneli kontot ja umbes 200 domeeni, ja pm.static või isegi dynamic ei päästaks mind. Siin on vaja ainult nõudmisel, sest rohkem kui kaks kolmandikku veebilehtedest teenib vähe liiklust või ei teenigi üldse, ja nõudmisel kõik alamprotsessid kukuvad kokku, säästes meile tohutult mälu! Õnneks on cPaneli arendajad seda märganud ja seadnud vaikeväärtuse nõudmisel. Varem, kui vaikeväärtus oli dünaamiline, ei olnud PHP-FPM üldse sobilik koormatud jagatud serverite jaoks. Paljud kasutasid suPHP, sest pm dünaamiline kasutatakse mälu isegi siis, kui cPanel PHP-FPM koopiad ja kontod on inaktiivsed. Tõenäoliselt ei soovi te suurte PHP-FPM koopiate arvuga serveris asuda (ühishosting) kõrge liikluse korral.

Kokkuvõte

Kui kasutate PHP-FPM-i ja teie liiklus on märkimisväärne, piiravad protsessihaldurid nõudmisel ja dünaamiline PHP-FPM-i jaoks ribalaiust, kuna neil on iseenesest kulud. Uurige oma süsteemi ja seadistage PHP-FPM-i protsessid vastavalt serveri maksimaalsele mahutavusele. Esmalt seadistage pm.max_children maksimaalse kasutamise pm sõltuvalt dünaamiline või nõudmisel, seejärel suurendage seda väärtust tasemeni, kus mälu ja protsessor töötavad ilma liigse koormuseta. Te märkate, et kuna pm static, kõik hoitakse mälus, liikluspiigid põhjustavad aja jooksul protsessori jaoks vähem tippe ja serveri ning protsessori keskmised koormused tasanduvad. PHP-FPM-i protsessi keskmine suurus sõltub veebi serverist ja vajab käsi-seadistust, seetõttu on rohkem automatiseeritud protsessihaldurid dünaamiline ja nõudmisel — populaarsed. Loodan, et artikkel oli kasulik.

UPD Lisatud on mõõdikute diagramm ab. Kui PHP-FPM protsessid on mälus, suureneb jõudlus mälutarbimise arvelt, kus nad ootavad. Leidke endale optimaalne variant.

Allikas: habr.com