🥇PHP-FPM beállítása: használjon pm static-ot a maximális teljesítmény érdekében

A cikk szerkesztetlen változata eredetileg itt jelent meg haydenjames.io és itt közzétesszük engedélyével. szerző.

Röviden elmondom, hogyan állíthatja be a PHP-FPM-et a legjobban, hogy növelje a sávszélességet, csökkentse a késleltetést és stabilabban használja a CPU és a memória erőforrásait. Alapértelmezés szerint a PHP-FPM PM (process manager, folyamatkezelő) beállítása dinamikus, ha pedig memóriahiány lép fel, érdemes beállítani ondemand. Hasonlítsuk össze a két vezérlési lehetőséget a php.net dokumentációja alapján, és nézzük meg, miben különbözik a kedvencem: Az új típus — pm nagy forgalom esetén:

pm = dinamikus — a gyermekprocesszek száma dinamikusan állítható be 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 (szemben a dinamikus létrehozással, amikor a pm.start_servers a szolgáltatás indításakor elindul).
pm = statikus — a gyermekprocesszek száma rögzített és a pm.max_children.

Részletekért lásd teljes listájában a php-fpm.conf globális direktíváknak.

A PHP-FPM folyamatkezelő hasonlóságai a CPU frekvencia szabályozójával

Lehet, hogy ez off-topiknak tűnik, de összekapcsolom a PHP-FPM beállításának témájával. Kinek ne akadozott volna már a CPU — laptopon, virtuális gépen vagy dedikált szerveren. Emlékszik a CPU frekvenciájának skálázására? Ezek a beállítások, amelyek elérhetők nix és Windows alatt, javíthatják a teljesítményt és a rendszer válaszidejét, ha a CPU frekvencia szabályozót ondemand Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata performance*-ra állítjuk. Ezúttal hasonlítsuk össze a leírásokat és nézzük meg a hasonlóságokat:

Governor = ondemand — dinamikus frekvenciaszabályozás a jelenlegi terhelés alapján. Hirtelen a maximális frekvenciára vált, majd csökkenti azt, amikor növekednek a leállási időszakok.
Governor = conservative = dinamikus frekvenciaszabályozás, amely a jelenlegi terhelés alapján történik. Simább a frekvencia növelése és csökkentése, mint az ondemand esetében.
Governor = performance — a frekvencia mindig maximális.

Részletekért lásd a CPU frekvencia szabályozó paraméterek teljes listájában.

Látja a hasonlóságot? Ezt a összehasonlítást szerettem volna bemutatni, hogy meggyőzzem önt, hogy a legjobb, ha a pm statikus beállítást használja a PHP-FPM-hez.

A CPU szabályozónál a beállítás performance segít biztonságosan növelni a teljesítményt, mert ez szinte teljesen attól függ, hogy a szerver processzorának határa mennyi. Ezen kívül vannak más tényezők is, mint a hőmérséklet, az akkumulátor töltöttsége (a laptopban) és más mellékhatások, amelyek a processzor 100%-os folyamatos működéséből adódnak. A teljesítménybeállítás a processzor leggyorsabb működését biztosítja. Olvasson el például róla, a Raspberry Pi force_turbo paraméteréről, amellyel az RPi panel a szabályozót fogja használni performance, ahol a teljesítménynövelés észlelhetőbb lesz a CPU alacsony órajellel.

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

A PHP-FPM paraméter pm statikus nagymértékben függ a szerveren található szabad memóriától. Ha kevés a memória, akkor jobb választani ondemand vagy dinamikus. Másrészt, ha van emlékezet, elkerülhetjük a PHP folyamatkezelő túlzott költségeit a pm beállításával Az új típus — a szerver maximális kapacitásához. Más szavakkal, ha mindent jól kiszámolunk, be kell állítani pm.static a PHP-FPM maximális folyamatainak számaként, amelyek futtathatók, anélkül, hogy problémákat okozna a memória vagy a cache hiányával. De ne állítsa túl magasra, hogy ne terhelje túl a processzorokat és ne halmozzon fel egy halom PHP-FPM műveletet, ami a végrehajtásra vár..

A fenti képernyőképen a szerver beállítása pm = static és pm.max_children = 100, és ez körülbelül 10 GB-ot elfoglal a meglévő 32 GB-ból. Figyelje meg a kiemelt oszlopokat, itt minden tiszta. 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 számára. Ezen a szinten körülbelül 70% a PHP-FPM gyermekfolyamatoknak még mindig tétlen. Ez azt jelenti, hogy a PHP-FPM mindig a szerver erőforrásainak maximális mennyiségén van beállítva, függetlenül a jelenlegi forgalomtól. Az inaktív folyamat a forgalom csúcsaira vár, és azonnal reagál. Nem kell várnia, hogy pm létrehozza a gyermekfolyamatokat, majd leállítja azokat, amikor lejár az időszak pm.process_idle_timeout. Nagyon nagy értéket állítottam be a pm.max_requests, mert ez egy munkaszerver, amelyben nincs memória szivárgás a PHP-ben. Beállíthatja a pm.max_requests = 0 statically, ha teljesen biztos a meglévő és jövőbeli PHP szkriptekben. De jobb, ha idővel újraindítjuk a szkripteket. Állítson be nagy számú kérést, hiszen el szeretnénk kerülni a felesleges pm költségeket. Például legalább pm.max_requests = 1000 — a másodpercenkénti kérések számától függően. pm.max_children A képernyőképen a parancs látható

A képernyőképen látható a parancs Linux top, felhasználó (user) és PHP-FPM név alapján szűrve. Csak az első 50 vagy ahhoz közeli folyamat látható (pontosan nem számoltam), de lényegében a top a terminálablakba belépő statisztikákat mutatja. Ebben az esetben a % CPU (%CPU) szerint van rendezve. Ahhoz, hogy az összes 100 PHP-FPM folyamatot láthassa, futtassa a következő parancsot:

top -bn1 | grep php-fpm

Mikor használjunk pm ondemand és dynamic módot

Ha pm-t használunk dinamikus, hasonló hibák léphetnek fel:

WARNING: [pool xxxx] túlterheltnek tűnik (lehet, hogy növelnie kell a pm.start_servers vagy pm.min/max_spare_servers értékét), 32 gyermek létrehozása, 4 inaktív és összesen 59 gyermek van

Próbálja meg módosítani a paramétert, a hiba nem fog eltűnni, mint ahogy a Serverfaulton le van írva. Ebben az esetben a pm.min érték túl kicsi volt, és mivel a webforgalom erősen változik, és vannak magas csúcsok és mély mélypontok, nehéz a pm-t megfelelően beállítani. dinamikus. Általában itt pm-t használnak, ondemand, ahogy a korábbi bejegyzésben javasolják.. De ez még rosszabb, mert ondemand nullára csökkenti az inaktív folyamatokat, amikor a forgalom alacsony vagy egyáltalán nincs, és végül akkor is szenvedni fog a forgalom változásainak költségeivel. Ha persze nem állította be az óriási várakozási időt. Ekkor inkább használja pm.static + magas számot, pm.max_requests.

PM, dinamikus és különösen ondemand hasznos lehet, ha több PHP-FPM medencével rendelkezik. Például, ha több cPanel fiókot vagy több weboldalt üzemeltet különböző medencékben. Van egy szerverem, ahol például 100+ cPanel fiók és körülbelül 200 domain található, és a pm.static vagy akár a dynamic nem segítene. Itt csak ondemand, mert a weboldalak több mint kétharmada kevés forgalmat kap vagy egyáltalán nem, és a ondemand minden gyermek folyamat leáll, ami rengeteg memóriát takarít meg! Szerencsére a cPanel fejlesztői észrevették ezt, és beállították az alapértelmezett értéket ondemand. Régebben, amikor az alapértelmezett érték volt dinamikus, a PHP-FPM egyáltalán nem volt alkalmas a túlterhelt megosztott szerverekhez. Sokan használták a suPHP-t,mert a pm dinamikus még inaktív medencék és cPanel fiókok esetén is memóriát fogyasztott a PHP-FPM. Valószínűleg, ha jó a forgalma, nem egy olyan szerveren fog elhelyezkedni, ahol sok PHP-FPM medence található (megosztott hosztolás).

Zárás

Ha PHP-FPM-t használ, és komoly a forgalma, a folyamatmenedzserek ondemand és dinamikus a PHP-FPM esetében korlátozni fogják a sávszélességet a saját költségeik miatt. Vizsgálja meg a rendszerét, és állítsa be a PHP-FPM folyamatokat a szerver maximális kapacitásához. Először állítsa be pm.max_children a maximális pm használattól függően dinamikus vagy ondemand, majd növelje ezt az értéket arra a szintre, ahol a memória és a processzor túlzott terhelés nélkül dolgozik. Észre fogja venni, hogy pm statikus, mivel minden a memóriában tárolódik, a forgalom csúcsai idővel kevesebb csúcsot okoznak a processzor számára, és a szerver és a processzor átlagos terhelése kiegyenlítődik. A PHP-FPM átlagos folyamata a webszervertől függ, és manuális beállítást igényel, ezért a jobban automatizált folyamatkezelők — dinamikus és ondemand — népszerűbbek. Remélhetőleg hasznos volt a cikk.

UPD Benchmark diagram hozzáadva ab. Ha a PHP-FPM folyamatok a memóriában vannak, a teljesítmény a memóriafogyasztás révén növekszik, ahol állnak és várnak. Találja meg a legjobb megoldást magának.