PHP-FPM sąranka: maksimaliam našumui naudokite pm static

Neredaguota šio straipsnio versija iš pradžių buvo paskelbta haydenjames.io ir paskelbtas čia su jos leidimu autorius.

Trumpai papasakosiu, kaip geriausiai sukonfigūruoti PHP-FPM, kad padidintumėte pralaidumą, sumažintumėte delsą ir nuosekliau naudotumėte procesorių bei atmintį. Pagal numatytuosius nustatymus PHP-FPM eilutė PM (procesų tvarkyklė) yra dinamiškas, o jei neturite pakankamai atminties, tada geriau įdiegti įpareigojimas. Palyginkime 2 valdymo parinktis pagal php.net dokumentaciją ir pažiūrėkime, kuo mano mėgstamiausia skiriasi nuo jų statinis pm esant dideliam srautui:

pm = dinaminis — antrinių procesų skaičius konfigūruojamas dinamiškai, remiantis šiomis direktyvomis: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = pagal pareikalavimą - procesai kuriami pagal poreikį (priešingai nei dinaminis kūrimas, kai paleidus paslaugą paleidžiamas pm.start_servers).
pm = statinis — antrinių procesų skaičius yra fiksuotas ir nurodomas parametru pm.max_vaikai.

Daugiau informacijos žr visas pasaulinių direktyvų sąrašas php-fpm.conf.

PHP-FPM proceso tvarkyklės ir procesoriaus dažnio valdiklio panašumai

Tai gali pasirodyti ne į temą, bet aš susiesiu tai su PHP-FPM konfigūravimo tema. Kas bent kartą nepatyrė procesoriaus sulėtėjimo - nešiojamajame kompiuteryje, virtualioje mašinoje ar skirtame serveryje. Prisiminkite procesoriaus dažnio mastelį? Šios parinktys galimos nix ir Windows gali pagerinti sistemos našumą ir reagavimą pakeisdami procesoriaus droselio nustatymą iš įpareigojimas apie spektaklis*. Šį kartą palyginkime aprašymus ir pažvelkime į panašumus:

gubernatorius=pagal pareikalavimą — dinaminis procesoriaus dažnio mastelio keitimas priklausomai nuo esamos apkrovos. Greitai peršoka į maksimalų dažnį ir sumažina jį, kai pailgėja neveiklumo periodai.
gubernatorius=konservatorius= dinaminis dažnio mastelis, priklausomai nuo esamos apkrovos. Padidina ir mažina dažnį sklandžiau nei pagal poreikį.
Gubernatorius = pasirodymas — dažnis visada maksimalus.

Daugiau informacijos žr visas procesoriaus dažnio reguliatoriaus parametrų sąrašas.

Matai panašumus? Norėjau parodyti šį palyginimą, kad įtikinčiau, jog geriausia jį naudoti pm statinis PHP-FPM.

Procesoriaus reguliatoriaus parametrui spektaklis padeda saugiai padidinti našumą, nes tai beveik visiškai priklauso nuo serverio procesoriaus limito. Be to, žinoma, yra ir tokių veiksnių kaip temperatūra, baterijos įkrovimas (nešiojamajame kompiuteryje) ir kiti šalutiniai poveikiai, kai procesorius nuolat veikia 100 %. Našumo nustatymas užtikrina greičiausią procesoriaus veikimą. Skaitykite, pavyzdžiui, apie force_turbo parametras Raspberry Pi, su kuriuo RPi skydelis naudos reguliatorių spektaklis, kur našumo pagerėjimas bus labiau pastebimas dėl mažo procesoriaus laikrodžio greičio.

Pm static naudojimas maksimaliam serverio našumui pasiekti

PHP-FPM parinktis pm statinis daugiausia priklauso nuo laisvos atminties serveryje. Jei atminties trūksta, geriau rinktis įpareigojimas arba dinamiškas. Kita vertus, jei turite atminties, galite išvengti PHP procesų tvarkyklės papildomų išlaidų nustatydami pm statinis iki didžiausios serverio talpos. Kitaip tariant, jei viskas gerai paskaičiuota, reikia nustatyti pm.statinis iki didžiausio PHP-FPM procesų kiekio, kurį galima vykdyti, nesukeliant problemų dėl mažos atminties ar talpyklos. Bet ne taip aukštai, kad apkrautų procesorius ir sukauptų krūvą PHP-FPM operacijų, laukiančių, kol bus įvykdytos..

Aukščiau esančioje ekrano kopijoje serveris turi pm = statinis ir pm.max_children = 100, ir tai užima maždaug 10 GB iš turimų 32. Atkreipkite dėmesį į paryškintus stulpelius, čia viskas aišku. Šioje ekrano kopijoje „Google Analytics“ buvo maždaug 200 aktyvių vartotojų (daugiau nei 60 sekundžių). Šiame lygyje maždaug 70 % PHP-FPM antrinių procesų vis dar neveikia. Tai reiškia, kad PHP-FPM visada yra nustatytas maksimaliam serverio išteklių kiekiui, nepaisant esamo srauto. Neveikiantis procesas laukia srauto piko ir reaguoja akimirksniu. Jums nereikia laukti, kol pm sukurs antrinius procesus ir nutrauks juos pasibaigus laikotarpiui pm.process_idle_timeout. Nustačiau labai didelę vertę pm.max_requestsnes tai veikiantis serveris be atminties nutekėjimo PHP. Galite įdiegti pm.max_requests = 0 su static, jei esate visiškai įsitikinęs esamais ir būsimais PHP scenarijais. Tačiau laikui bėgant geriau paleisti scenarijus iš naujo. Nustatykite didelį užklausų skaičių, nes norime išvengti nereikalingų pm išlaidų. Pavyzdžiui, bent jau pm.max_requests = 1000 - priklausomai nuo kiekio pm.max_vaikai ir užklausų skaičius per sekundę.

Ekrano kopijoje rodoma komanda Linux viršuje, filtruojamas pagal u (vartotoją) ir PHP-FPM vartotojo vardą. Rodomi tik pirmieji 50 procesų (tiksliai neskaičiavau), bet iš esmės viršuje rodoma geriausia statistika, kuri telpa į terminalo langą. Šiuo atveju rūšiuojama pagal %CPU. Norėdami pamatyti visus 100 PHP-FPM procesų, paleiskite komandą:

top -bn1 | grep php-fpm

Kada naudoti pm ondemand ir dynamic

Jei naudosi pm dinamiškas, atsiranda tokių klaidų:

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

Pabandykite pakeisti parametrą, klaida neišnyks, pvz aprašyta šiame įraše apie Serverfault. Šiuo atveju pm.min reikšmė buvo per maža, o žiniatinklio srautas labai skiriasi ir turi aukštas viršūnes bei gilius slėnius, sunku tinkamai sureguliuoti pm. dinamiškas. Dažniausiai naudojamas pm įpareigojimas, kaip patariama tame pačiame įraše. Bet tai dar blogiau, nes įpareigojimas nutraukia tuščiosios eigos procesus iki nulio, kai srautas yra mažas arba jo visai nėra, ir jūs vis tiek turėsite pakeisti srautą. Nebent, žinoma, nustatysite didžiulį laukimo laiką. Ir tada geriau naudoti pm.statinis + didelis skaičius pm.max_requests.

PM dinamiškas ir ypač įpareigojimas gali praversti, jei turite kelis PHP-FPM telkinius. Pavyzdžiui, priglobiate kelias „cPanel“ paskyras arba kelias svetaines skirtinguose telkiniuose. Turiu serverį su tarkim 100+ cpanel paskyrų ir apie 200 domenų, o pm.static ar net dynamic manęs neišgelbėtų. Viskas, ko jums reikia čia įpareigojimas, juk daugiau nei du trečdaliai svetainių sulaukia nedidelio srauto arba jo visai nesulaukia, o su įpareigojimas visi vaiko procesai nukris, o tai sutaupys daug atminties! Laimei, cPanel kūrėjai tai pastebėjo ir nustatė numatytąją vertę įpareigojimas. Anksčiau, kai numatytasis buvo dinamiškas, PHP-FPM visiškai netiko užimtiems bendriems serveriams. Daugelis naudojo suPHP, nes pm dinamiškas sunaudojama atmintis net esant neaktyviems telkiniams ir cPanel PHP-FPM paskyroms. Greičiausiai, jei srautas geras, nebūsite talpinami serveryje su daugybe PHP-FPM telkinių (bendrasis priegloba).

išvada

Jei naudojate PHP-FPM ir srautas yra didelis, procesų valdytojai įpareigojimas и dinamiškas PHP-FPM pralaidumas bus ribotas dėl jiems būdingų pridėtinių išlaidų. Supraskite savo sistemą ir sukonfigūruokite PHP-FPM procesus pagal maksimalią serverio talpą. Pirmas rinkinys pm.max_vaikai priklausomai nuo maksimalaus pm naudojimo dinamiškas arba įpareigojimas, tada padidinkite šią reikšmę iki tokio lygio, kad atmintis ir procesorius veiktų be perkrovos. Tai pastebėsite su pm statinis, kadangi jūs turite viską atmintyje, srauto šuolis laikui bėgant sukels mažiau procesoriaus šuolių, o serverio ir procesoriaus apkrovos vidurkis išsilygins. Vidutinis PHP-FPM proceso dydis priklauso nuo žiniatinklio serverio ir reikalauja rankinio konfigūravimo, todėl yra daugiau automatizuotų procesų valdytojų dinamiškas и įpareigojimas - populiaresnis. Tikiuosi, kad straipsnis buvo naudingas.

DUP Pridėta lyginamoji diagrama ab. Jei PHP-FPM procesai yra atmintyje, našumas padidėja atminties suvartojimo sąskaita ten, kur jie sėdi ir laukia. Raskite sau geriausią variantą.

Šaltinis: www.habr.com