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

Toimetamata artikkel ilmus esmakordselt aadressil haydenjames.io ja avaldatakse siin tema autor.

Kus ma lühidalt õpetan, kuidas PHP-FPM-i kõige paremini seadistada, et suurendada läbilaskevõimet, vähendada latentsust ja stabiilsemalt kasutada protsessorite ja mäluse ressursse. Vaikimisi on PM (process manager, protsessihaldur) PHP-FPM-is seadistatud väärtusele dynamic, ja kui teil on mälu puudus, siis on parem seadistada ondemand. Võtame ette 2 haldusviisi php.net dokumentatsiooni põhjal ja vaatame, milles need minu lemmikust erinevad static suurte liiklusmahtude jaoks:

pm = dynamic — alampõhised protsesside arv seadistatakse dünaamiliselt järgmiste direktiivide põhjal: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — protsessid luuakse nõudmisel (erinevalt dünaamilisest loomise mehhanismist, kus pm.start_servers käivituvad teenuse käivitamisel).
pm = static — alampõhiste protsesside arv on fikseeritud ja määratud parameetriga pm.max_children.

Üksikasjade kohta vaata PHP-FPM.conf globaalsete direktiivide täielik loetelu.

PHP-FPM protsessihalduri sarnasus protsessori sageduse reguleerijaga

See võib tunduda off-topic, kuid ma kavatsen selle PHP-FPM seadistamise teemaga siduda. Kas keegi kogenud, et protsessor aeglustus — toteedes sülearvutis, virtuaalmasinas või pühendatud serveris. Kas mäletate protsessori sageduse skaleerimist? Need parameetrid, mis on saadaval nix ja Windows, võivad süsteemi jõudlust ja reageerimiskiirust suurendada, kui muuta protsessori regulaatori parameetrit ondemand . Tundub, et performance*. Seekord võrdleme kirjeldusi ja vaatame sarnasusi:

Governor = ondemand — dünaamiline protsessori sageduse skaleerimine vastavalt praegusele koormusele. Tõuseb äkki maksimaalsele sagedusele ning seejärel alandab seda, kui suureneb seisakute aeg.
Governor = conservative = dünaamiline skaleerimine vastavalt praegusele koormusele. Suurendab ja vähendab sagedust sujuvamalt kui ondemand.
Governor = performance — sagedus on alati maksimaalne.

Üksikasjade kohta vaata protsessori sageduse regulaatori parameetrite täielik loetelu.

Küsite sarnasusi? Soovisin näidata seda võrdlust, et veenda teid, et on parem kasutada pm static PHP-FPM-i jaoks.

Protsessori regulaatori parameeter performance aitab aitab aitab ohutult suurendada jõudlust, kuna see sõltub peaaegu täielikult serveri protsessori limiidist. Lisaks on muid tegureid, nagu temperatuur, aku laadimine (portatiivses arvutis) ja teised kõrvalmõjud, kui protsessor töötab 100% -selt. Jõudluse seadistamine tagab protsessori kiireima töö. Loe näiteks parameeter force_turbo Raspberry Pi-s, mille abil 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 serveris olevast vabast mälust. Kui mälu on vähe, on parem valida ondemand või dynamic. Teisest küljest, kui mälu on olemas, saab vältida lisakulusid PHP protsessi haldurile, seadistades pm static serveri maksimaalsele mahule. Teisisõnu, kui kõik on hästi läbi arvutatud, tuleks seadistada pm.static PHP-FPM, mis võib töötada, ilma et see looks probleeme mälu või vahemäluga. Kuid mitte liiga kõrgele, et mitte üle koormata protsessoreid ja kuhjata PHP-FPM operatsioone, mis ootavad täitmist..

Ülaloleval ekraanipildil on serveris seadistatud pm = static ja pm.max_children = 100, mis võtab ligikaudu 10 GB saadavast 32 GB-st. Pange tähele esile tõstetud veerge, siin on kõik selge. Sellel ekraanipildil oli umbes 200 aktiivset kasutajat (rohkem kui 60 sekundi jooksul) Google Analyticsis. Sel tasemel on umbes 70% PHP-FPM alamelementidest endiselt inaktiivsed. See tähendab, et PHP-FPM on alati seadistatud serveri ressursside maksimaalsele mahule sõltumata praegusest liiklusest. Ooteprotsess ootab liikluse tippe ja reageerib kohe. Te ei pea ootama, kuni pm loob alamehhanisme ja lõpetab need, kui aeg on möödunud. pm.process_idle_timeout. Olen seadnud väga suure väärtuse pm.max_requests, kuna see on tööserver ilma mälulekketa PHP-s. Saate seadistada pm.max_requests = 0 staticuga, kui olete täiesti kindel, et olemasolevates ja tulevastes PHP skriptides ei ole probleeme. Kuid parem on aeg-ajalt skripte taaskäivitada. Seadistage suur arv päringuid, et vältida lisakulusid. Näiteks vähemalt pm.max_requests = 1000 kasutamise sõltuvalt arvust pm.max_children ja päringute arvust sekundis.

Ekraanipildil on näidatud käsk Linux top, filtreeritud u (kasutaja) ja PHP-FPM kasutajanime järgi. Näidatud on vaid 50 või nii protsessi (täpselt ei lugenud), aga põhimõtteliselt näitab top top statistikat, mis mahub terminali aknasse. Sel juhul on sortimine % CPU (%CPU) järgi. Kõikide 100 PHP-FPM protsessi nägemiseks käivitage käsk:

top -bn1 | grep php-fpm

Millal kasutada pm ondemand ja dynamic

Kui kasutada pm dynamic, tekivad sarnased vead:

HOIATUS: [basin xxxx] paistab hõivatud (võib-olla peate suurendama pm.start_servers, või pm.min/max_spare_servers), sünteesitakse 32 last, 4 on pea, ja 59 kokku last

Proovige seada parameetrit, error ei kao kusagile, nagu on kirjeldatud selles postituses Serverfaultis. Sel juhul oli pm.min väärtus liiga madal, ja kuna veebiliiklus on väga kõikehõlmav ja on suuri tippe ja sügavaid allakäike, on pm seadistamine keeruline. dynamic. Tavaliselt kasutatakse pm ondemand, nagu soovitatakse samas postituses. Kuid see on veel hullem, sest ondemand lõpetab passiivsed protsessid nulli, kui liiklust on vähe või pole üldse, ja lõpuks peate ikkagi tegelema liikumise muutumisega. Kui muidugi te ei ole seadnud suurt ooteaega. Ja siis on parem kasutada pm.static + suurt arvu pm.max_requests.

PM dynamic ja eriti ondemand võivad olla kasulikud, kui teil on mitu PHP-FPM basaini. Näiteks hostite mitut cPaneli kontot või mitut veebisaiti erinevates basseinides. Mul on server, kus on näiteks 100+ cpaneli kontot ja umbes 200 domeeni ning pm.static või isegi dynamic ei päästaks mind. Siin on vajalik ainult ondemand, sest rohkem kui kaks kolmandikku veebisaitidest saab vähe liiklust või üldse mitte, ja ondemand kõik lastel protsessid kukuvad ära, mis säästab meile tohutult mälu! Õnneks on cPaneli arendajad selle märkama ja seadnud vaikimisi väärtuse ondemand. Varem, kui vaikimisi väärtus oli dynamic, siis PHP-FPM ei sobinud ülekoormatud jagatud serveritesse. Paljud kasutasid suPHP, sest pm dynamic kasutas mälu isegi passiivsete basseinide ja cPaneli kontode puhul PHP-FPM-i. Tõenäoliselt, kui teie liiklus on hea, siis te ei hosti serveris, millel on palju PHP-FPM basseinide (jagatud majutamine).

Kokkuvõte

Kui kasutate PHP-FPM-i ja teie liiklus on tõsine, siis protsesside haldurid ondemand ja dynamic PHP-FPM jaoks piiravad läbilaskevõimet iseloomulike kulude tõttu. Uurige oma süsteemi ja seadistage PHP-FPM protsessid vastavalt serveri maksimaalsele mahtuvusele. Alustuseks määratlege pm.max_children sõltuvalt pm maksimaalsest kasutamisest dynamic või ondemand, ja seejärel suurendage seda väärtust tasemeni, kus mälu ja protsessor töötavad ilma liigse koormuseta. Te märkate, et pm static, kuna teil on kõik salvestatud mällu, põhjustavad liiklushooajad ajaga vähem tippkoormusi protsessorile ja serveri ning protsessori keskmised koormused tasanduvad. PHP-FPM keskmine protsessi suurus sõltub veebiserverist ja vajab käsitsi seadistamist, seega on automaatsemad protsessihaldurid — dynamic ja ondemand — populaarsemad. Loodan, et artikkel oli kasulik.

UPD Lisatud tulemuste diagramm ab. Kui PHP-FPM protsessid on mälus, suureneb jõudlus mälutarbimise tõttu, kus nad ootavad. Leidke endale optimaalne lahendus.

Allikas: habr.com