PHP-FPM beállítás: a pm static használata a maximális teljesítmény érdekében

A cikk szerkesztetlen változata eredetileg ekkor jelent meg haydenjames.io és az ő engedélyével publikálták itt szerző.

Dióhéjban elmondom, hogyan lehet a legjobban beállítani a PHP-FPM-et az átviteli sebesség növelése, a késleltetés csökkentése, valamint a CPU és a memória konzisztensebb használata érdekében. Alapértelmezés szerint a PM (folyamatkezelő) sor a PHP-FPM-ben dinamikus, és ha nincs elég memóriája, akkor jobb telepíteni igény szerint. Hasonlítsunk össze 2 vezérlési lehetőséget a php.net dokumentációja alapján, és nézzük meg, miben tér el a kedvencem ezektől statikus délután nagy forgalom esetén:

pm = dinamikus — a gyermekfolyamatok száma dinamikusan van konfigurálva a következő direktívák alapján: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand - a folyamatok igény szerint jönnek létre (ellentétben a dinamikus létrehozással, amikor a pm.start_servers elindul a szolgáltatás indulásakor).
pm = statikus — a gyermekfolyamatok száma rögzített, és a paraméter jelzi pm.max_children.

A részletekért lásd a globális direktívák teljes listája php-fpm.conf.

Hasonlóságok a PHP-FPM folyamatkezelő és a CPU frekvenciavezérlő között

Ez offtopicnak tűnhet, de ezt a PHP-FPM konfiguráció témaköréhez fogom kapcsolni. Ki ne tapasztalt volna legalább egyszer processzorlassulást – laptopon, virtuális gépen vagy dedikált szerveren. Emlékszel a CPU frekvencia skálázására? Ezek a lehetőségek állnak rendelkezésre A nix és a Windows javíthatja a rendszer teljesítményét és válaszkészségét a processzor fojtószelep beállításának megváltoztatásával igény szerint on teljesítmény*. Ezúttal hasonlítsuk össze a leírásokat, és nézzük a hasonlóságokat:

kormányzó=ondemand — a processzor frekvenciájának dinamikus skálázása az aktuális terheléstől függően. Gyorsan ugrik a maximális frekvenciára, majd csökkenti azt az inaktivitási időszakok növekedésével.
kormányzó=konzervatív= dinamikus frekvenciaskálázás az aktuális terheléstől függően. A frekvenciát simábban növeli és csökkenti, mint az igény szerint.
Kormányzó = teljesítmény — a frekvencia mindig maximális.

A részletekért lásd a processzor frekvenciaszabályozó paramétereinek teljes listája.

Látod a hasonlóságokat? Meg akartam mutatni ezt az összehasonlítást, hogy meggyőzzem Önt arról, hogy ezt a legjobb használni pm statikus PHP-FPM-hez.

A processzor szabályozó paraméteréhez teljesítmény segít biztonságosan növelni a teljesítményt, mert szinte teljes mértékben a szerver CPU-korlátjától függ. Ezen kívül természetesen vannak olyan tényezők is, mint a hőmérséklet, az akkumulátor töltöttsége (laptopban) és egyéb mellékhatások, ha a processzor folyamatosan 100%-on működik. A teljesítménybeállítás biztosítja a processzor leggyorsabb teljesítményét. Olvassa el például kb force_turbo paraméter a Raspberry Pi-ben, amellyel az RPi panel fogja használni a szabályozót teljesítmény, ahol a teljesítményjavulás az alacsony CPU órajel miatt érezhetőbb lesz.

A pm static használata a szerver maximális teljesítményének eléréséhez

PHP-FPM opció pm statikus nagyban függ a szerver szabad memóriájától. Ha kevés a memória, jobb a választás igény szerint vagy dinamikus. Másrészt, ha van memóriád, a pm beállításával elkerülheted a PHP folyamatkezelő túlterhelését statikus a maximális szerverkapacitásig. Más szóval, ha minden jól van kiszámítva, meg kell állapítania pm.statikus a végrehajtható PHP-FPM folyamatok maximális mennyiségére, anélkül, hogy problémákat okozna az alacsony memória vagy gyorsítótár miatt. De nem olyan magasan, hogy túlterhelje a processzorokat, és felhalmozzon egy csomó PHP-FPM műveletet, amelyek végrehajtásra várnak..

A fenti képernyőképen a szerver rendelkezik pm = statikus és pm.max_children = 100, és ez megközelítőleg 10 GB-ot foglal el a rendelkezésre álló 32-ből. Ügyeljen a kiemelt oszlopokra, itt minden világos. Ezen a képernyőképen körülbelül 200 aktív felhasználó volt (több mint 60 másodpercig) a Google Analytics szolgáltatásban. Ezen a szinten a PHP-FPM gyermekfolyamatok körülbelül 70%-a még mindig tétlen. Ez azt jelenti, hogy a PHP-FPM mindig a maximális szervererőforrásra van állítva, függetlenül az aktuális forgalomtól. A tétlen folyamat a forgalmi csúcsokra vár, és azonnal reagál. Nem kell addig várnod pm gyermekfolyamatokat hoz létre, majd az időszak lejártakor leállítja őket pm.process_idle_timeout. Nagyon magasra állítottam az értéket pm.max_requestsmert ez egy működő szerver, melyben nincs memóriaszivárgás a PHP-ben. Telepítheti pm.max_requests = 0 static-al, ha teljesen magabiztos a meglévő és jövőbeli PHP szkriptekben. De jobb, ha idővel újra futtatja a szkripteket. Állítson be nagy számú kérést, mert szeretnénk elkerülni a felesleges pm költségeket. Például legalább pm.max_requests = 1000 - mennyiségtől függően pm.max_children és a kérések száma másodpercenként.

A képernyőképen a parancs látható Linux top, u (felhasználó) és PHP-FPM felhasználónév alapján szűrve. Csak az első vagy 50 folyamat látható (nem számoltam pontosan), de lényegében a top mutatja a terminál ablakba illeszkedő legjobb statisztikát. Ebben az esetben % CPU (%CPU) szerint rendezve. Az összes 100 PHP-FPM folyamat megtekintéséhez futtassa a parancsot:

top -bn1 | grep php-fpm

Mikor kell használni a pm ondemand és dinamikus funkciót

Ha pm-et használsz dinamikus, ehhez hasonló hibák fordulnak elő:

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óbáld meg megváltoztatni a paramétert, a hiba nem tűnik el, pl ebben a bejegyzésben a Serverfaultról leírva. Ebben az esetben a pm.min érték túl kicsi volt, és mivel a webes forgalom nagyon változó, magas csúcsokkal és mély völgyekkel rendelkezik, nehéz megfelelően beállítani a pm értéket. dinamikus. Általában pm használatos igény szerint, ahogy ugyanabban a bejegyzésben tanácsolják. De ez még rosszabb, mert igény szerint nullára állítja le a tétlen folyamatokat, ha kicsi vagy nincs forgalom, és továbbra is a forgalom megváltoztatásával kell megbirkózni. Kivéve persze, ha nagy várakozási időt állít be. És akkor jobb használni pm.statikus + magas szám pm.max_requests.

PM dinamikus és különösen a igény szerint hasznos lehet, ha több PHP-FPM készlettel rendelkezik. Például több cPanel-fiókot vagy több webhelyet tárol különböző készletekben. Van egy szerverem mondjuk 100+ cpanel fiókkal és kb 200 domainnel, és a pm.static vagy akár a dynamic nem mentene meg. Itt csak az kell igény szerint, elvégre a webhelyek több mint kétharmada csekély vagy egyáltalán nem forgalommal, és azzal igény szerint minden gyermek folyamat leesik, ami sok memóriát takarít meg! Szerencsére a cPanel fejlesztői észrevették ezt, és alapértelmezettre állították az értéket igény szerint. Korábban, amikor az alapértelmezett volt dinamikus, a PHP-FPM egyáltalán nem volt alkalmas elfoglalt megosztott szerverekhez. Sokan használtak suPHP, mert pm dinamikus még üresjárati készletekkel és cPanel PHP-FPM fiókokkal is fogyasztotta a memóriát. Valószínűleg, ha jó a forgalom, akkor nem lesz olyan szerver, amely sok PHP-FPM-készlettel rendelkezik (megosztott tárhely).

Következtetés

Ha PHP-FPM-et használ és nagy a forgalom, akkor a folyamatmenedzserek igény szerint и dinamikus A PHP-FPM átviteli sebessége korlátozott lesz a benne rejlő többletterhelés miatt. Ismerje meg rendszerét, és állítsa be a PHP-FPM folyamatokat a maximális szerverkapacitásnak megfelelően. Első szett pm.max_children a maximális pm használattól függően dinamikus vagy igény szerint, majd növelje ezt az értéket olyan szintre, ahol a memória és a processzor túlterhelés nélkül fog működni. Ezzel észre fogod venni pm statikus, mivel minden a memóriában van, a forgalmi kiugrások idővel kevesebb CPU-csúcsot okoznak, és a szerver és a CPU terhelési átlaga kiegyenlítődik. Az átlagos PHP-FPM folyamatméret a webszervertől függ, és manuális konfigurálást igényel, így több automatizált folyamatkezelő dinamikus и igény szerint - népszerűbb. Remélem hasznos volt a cikk.

UPD Hozzáadott benchmark diagram ab. Ha a PHP-FPM folyamatok a memóriában vannak, a teljesítmény a memóriafelhasználás rovására nő, ahol ülnek és várnak. Találja meg magának a legjobb megoldást.

Forrás: will.com