PHP-FPM uppsetning: notaðu pm static fyrir hámarksafköst

Óbreytt útgáfa af þessari grein var upphaflega birt á haydenjames.io og birt hér með hennar leyfi höfundurinn.

Ég skal segja þér í stuttu máli hvernig best er að stilla PHP-FPM til að auka afköst, draga úr leynd og nota örgjörva og minni samkvæmari. Sjálfgefið er að PM (process manager) línan í PHP-FPM er dynamic, og ef þú ert ekki með nóg minni, þá er betra að setja upp ondemand. Berum saman 2 stjórnunarvalkosti byggða á php.net skjölunum og sjáum hvernig uppáhaldið mitt er frábrugðið þeim truflanir pm fyrir mikla umferð:

pm = dýnamískt — fjöldi undirferla er stilltur á virkan hátt byggt á eftirfarandi tilskipunum: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = eftirspurn - ferli eru búin til á eftirspurn (öfugt við kraftmikla sköpun, þegar pm.start_servers eru ræstir þegar þjónustan byrjar).
pm = kyrrstöðu — fjöldi undirferla er fastur og er sýndur með færibreytunni pm.max_börn.

Sjá nánar heill listi yfir alþjóðlegar tilskipanir php-fpm.conf.

Líkindi milli PHP-FPM vinnslustjórans og CPU tíðni stjórnanda

Þetta kann að virðast offtopic, en ég ætla að tengja þetta við efnið PHP-FPM stillingar. Hver hefur ekki upplifað hægagang á örgjörva að minnsta kosti einu sinni - á fartölvu, sýndarvél eða sérstökum netþjóni? Manstu eftir örgjörva tíðnikvarða? Þessir valkostir eru í boði fyrir nix og Windows geta bætt afköst kerfisins og svörun með því að breyta inngjöf örgjörvans úr ondemand á frammistaða*. Að þessu sinni skulum við bera saman lýsingarnar og skoða líkindin:

landstjóri = eftirspurn — kraftmikil stigstærð á tíðni örgjörva eftir núverandi álagi. Hoppar hratt upp í hámarkstíðni og dregur síðan úr henni eftir því sem tímabil óvirkni aukast.
landstjóri=íhaldssamur= kraftmikil tíðnikvarða eftir núverandi álagi. Eykur og lækkar tíðnina á auðveldari hátt en eftirspurn.
Seðlabankastjóri = frammistaða — tíðni er alltaf hámark.

Sjá nánar fullur listi yfir færibreytur örgjörva tíðnieftirlits.

Sjáðu líkindin? Mig langaði að sýna þennan samanburð til að sannfæra þig um að það sé best að nota hann pm truflanir fyrir PHP-FPM.

Fyrir færibreytu örgjörvajafnarans flutningur hjálpar til við að auka afköst á öruggan hátt vegna þess að það er nánast algjörlega háð CPU takmörkum þjónsins. Til viðbótar þessu eru auðvitað líka þættir eins og hitastig, hleðsla rafhlöðunnar (í fartölvu) og aðrar aukaverkanir af því að keyra stöðugt örgjörvann á 100%. Frammistöðustillingin tryggir hraðasta afköst örgjörva. Lestu til dæmis um force_turbo breytu í Raspberry Pisem RPi spjaldið mun nota þrýstijafnarann ​​með flutningur, þar sem frammistöðuaukningin verður meira áberandi vegna lágs CPU klukkuhraða.

Notkun pm static til að ná hámarksafköstum netþjónsins

PHP-FPM valkostur pm truflanir fer að miklu leyti eftir lausu minni á þjóninum. Ef minni er lítið er betra að velja ondemand eða dynamic. Á hinn bóginn, ef þú ert með minni, geturðu forðast PHP vinnslustjóra kostnaðar með því að stilla pm truflanir að hámarks getu netþjóns. Með öðrum orðum, ef allt er reiknað vel, þarftu að staðfesta pm.static að hámarksmagni PHP-FPM ferla sem hægt er að framkvæma, án þess að skapa vandamál með lítið minni eða skyndiminni. En ekki svo hátt að það yfirgnæfir örgjörvana og safnar fullt af PHP-FPM aðgerðum sem bíða eftir að verða framkvæmdar.

Í skjáskotinu hér að ofan hefur þjónninn pm = truflanir og pm.max_children = 100, og þetta tekur um það bil 10 GB af tiltækum 32. Gefðu gaum að auðkenndu dálkunum, allt er skýrt hér. Í þessari skjámynd voru um það bil 200 virkir notendur (meira en 60 sekúndur) í Google Analytics. Á þessu stigi eru um það bil 70% af PHP-FPM barnaferlum enn aðgerðalaus. Þetta þýðir að PHP-FPM er alltaf stillt á hámarksmagn netþjónaauðlinda óháð núverandi umferð. Aðgerðarlaus ferli bíður eftir umferðartoppum og bregst samstundis við. Þú þarft ekki að bíða þangað til pm mun búa til undirferli og slíta þeim síðan þegar tímabilið rennur út pm.process_idle_timeout. Ég stillti gildið á mjög hátt pm.max_requestsvegna þess að þetta er vinnandi þjónn án minnisleka í PHP. Þú getur sett upp pm.max_requests = 0 með static ef þú ert fullkomlega öruggur í núverandi og framtíðar PHP forskriftum. En það er betra að keyra handritin aftur með tímanum. Settu mikinn fjölda beiðna vegna þess að við viljum forðast óþarfa pm kostnað. Til dæmis, að minnsta kosti pm.max_requests = 1000 - fer eftir magni pm.max_börn og fjölda beiðna á sekúndu.

Skjáskotið sýnir skipunina Linux toppur, síað af u (notanda) og PHP-FPM notandanafni. Aðeins fyrstu 50 eða svo ferlarnir eru sýndir (ég taldi ekki nákvæmlega), en efst sýnir í raun efstu tölfræðina sem passa inn í flugstöðvargluggann. Í þessu tilviki raðað eftir % CPU (%CPU). Til að sjá öll 100 PHP-FPM ferlana skaltu keyra skipunina:

top -bn1 | grep php-fpm

Hvenær á að nota pm ondemand og dynamic

Ef þú notar pm dynamic, villur eins og þessar koma upp:

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

Prófaðu að breyta breytu, villan mun ekki hverfa, eins og lýst í þessari færslu á Serverfault. Í þessu tilviki var pm.min gildið of lítið og þar sem vefumferð er svo breytileg og með háa tinda og djúpa dal er erfitt að stilla pm nægilega vel. dynamic. Venjulega er pm notað ondemand, eins og ráðlagt er í sömu færslu. En þetta er enn verra, vegna þess ondemand lýkur aðgerðalausum ferlum í núll þegar það er lítil eða engin umferð, og þú endar samt með kostnaðinn af breyttri umferð. Nema auðvitað að þú setjir mikinn biðtíma. Og þá er betra að nota pm.static + há tala pm.max_requests.

PM dynamic og sérstaklega ondemand gæti komið sér vel ef þú ert með margar PHP-FPM laugar. Til dæmis hýsir þú marga cPanel reikninga eða margar vefsíður í mismunandi laugum. Ég er með netþjón með til dæmis 100+ cpanel reikningum og um 200 lénum og pm.static eða jafnvel dynamic myndi ekki bjarga mér. Allt sem þú þarft hér er ondemand, þegar öllu er á botninn hvolft fá meira en tveir þriðju vefsíðna litla sem enga umferð, og með ondemand allir barnaferli falla af, sem mun spara okkur mikið minni! Sem betur fer tóku cPanel verktaki eftir þessu og stilltu gildið á sjálfgefið ondemand. Áður, þegar sjálfgefið var dynamic, PHP-FPM hentaði alls ekki fyrir upptekna sameiginlega netþjóna. Margir hafa notað suPHP, því kl dynamic neytt minni jafnvel með aðgerðalausum laugum og cPanel PHP-FPM reikningum. Líklegast, ef umferðin er góð, verður þú ekki hýst á netþjóni með miklum fjölda PHP-FPM lauga (samnýtt hýsing).

Ályktun

Ef þú ert að nota PHP-FPM og umferðin þín er mikil, þá eru vinnslustjórar ondemand и dynamic fyrir PHP-FPM verður takmörkuð afköst vegna eðlislægra kostnaðar. Skildu kerfið þitt og stilltu PHP-FPM ferla í samræmi við hámarksgetu netþjónsins. Fyrsta sett pm.max_börn fer eftir hámarksnotkun pm dynamic eða ondemand, og hækka síðan þetta gildi upp á það stig að minni og örgjörvi virka án þess að vera of mikið álag. Þú munt taka eftir því með pm truflanir, þar sem þú ert með allt í minni, munu umferðaraukar valda færri örgjörva toppa með tímanum og meðaltal álags miðlara og örgjörva jafnast út. Að meðaltali PHP-FPM ferlarstærð fer eftir vefþjóninum og krefst handvirkrar stillingar, svo sjálfvirkari ferlistjórar eru dynamic и ondemand - vinsælli. Ég vona að greinin hafi verið gagnleg.

DUP Viðmiðunarriti bætt við ab. Ef PHP-FPM ferlar eru í minni eykst árangur á kostnað minnisnotkunar þar sem þeir sitja og bíða. Finndu besta kostinn fyrir sjálfan þig.

Heimild: www.habr.com