Nastavení PHP-FPM: používáme pm static pro maximální výkon

Needitorovaná verze článku byla původně publikována na haydenjames.io a je zde zveřejněna se souhlasem její autora.

V několika slovech vám povím, jak nejlépe nastavit PHP-FPM, aby se zvýšila propustnost, snížila latence a stabilněji využívaly procesorové zdroje a paměť. Ve výchozím nastavení má řádek PM (process manager, správce procesů) v PHP-FPM hodnotu dynamic, a pokud máte nedostatek paměti, je lepší nastavit ondemand. Pojďme porovnat 2 varianty správy na základě dokumentace php.net a podívat se, čím se liší moje oblíbené static pm pro vysoký objem provozu:

pm = dynamic — počet podřízených procesů se nastavuje dynamicky na základě následujících direktiv: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — procesy se vytvářejí na požádání (na rozdíl od dynamického vytváření, kdy se pm.start_servers spouští při spuštění služby).
pm = static — počet podřízených procesů je pevně stanoven a uvádí se parametrem pm.max_children.

Podrobnosti viz v úplném seznamu globálních direktiv php-fpm.conf.

Podobnosti procesního manažera PHP-FPM s regulátorem frekvence procesoru

Může to vypadat jako odbočka, ale chci to spojit s tématem nastavení PHP-FPM. Kdo se někdy nesetkal se zpomalením procesoru — na notebooku, virtuálním stroji nebo dedikovaném serveru. Pamatujete na škálování frekvence procesoru? Tyto parametry, dostupné pro nix a Windows, mohou zlepšit výkon a rychlost odezvy systému, pokud změníte parametr regulátoru procesoru na ondemand na performance*. Tentokrát srovnejme popisy a podívejme se na podobnosti:

Governor = ondemand — dynamické škálování frekvence procesoru v závislosti na aktuálním zatížení. Náhle přechází na maximální frekvenci a poté ji snižuje, když se zvyšují periody nečinnosti.
Governor = conservative = dynamické škálování frekvence v závislosti na aktuálním zatížení. Zvyšuje a snižuje frekvenci plynuleji než ondemand.
Governor = performance — frekvence je vždy maximální.

Podrobnosti viz v úplném seznamu parametrů regulátoru frekvence procesoru.

Vidíte podobnost? Chtěl jsem ukázat toto srovnání, abych vás přesvědčil, že nejlepší možností je použít pm static pro PHP-FPM.

Pro regulátor procesoru je parametr performance pomáhá bezpečně zvýšit výkon, protože téměř zcela závisí na limitu procesoru serveru. Kromě toho samozřejmě existují i další faktory, jako je teplota, stav baterie (v notebooku) a další vedlejší efekty trvalého využívání procesoru na 100 %. Nastavení výkonu zajišťuje nejrychlejší fungování procesoru. Přečtěte si například o parametru force_turbo v Raspberry Pi, se kterým panel RPi použije regulátor performance, kde zlepšení výkonu bude patrnější díky nízké frekvenci jádra.

Použití pm static k dosažení maximálního výkonu serveru

Parametr PHP-FPM pm static do značné míry závisí na volné paměti na serveru. Pokud je paměti málo, je lepší zvolit ondemand nebo dynamic. Na druhou stranu, pokud máte paměť, můžete se vyhnout zbytečným nákladům správce procesu PHP tím, že nastavíte pm static na maximální kapacitu serveru. Jinými slovy, pokud vše správně spočítáte, je třeba nastavit pm.static na maximální objem procesů PHP-FPM, které mohou být spuštěny, aniž by způsobovaly problémy s nedostatkem paměti nebo cache. Ale ne tak vysoko, aby přetížily procesory a vytvořily spoustu procesů PHP-FPM, které čekají na vykonání.

Na výše uvedeném snímku obrazovky má server nastaven pm = static a pm.max_children = 100, a to zabírá přibližně 10 GB z dostupných 32. Všimněte si zvýrazněných sloupců, tady je vše jasné. Na tomto snímku bylo přibližně 200 aktivních uživatelů (déle než 60 sekund) v Google Analytics. V této úrovni je přibližně 70 % podřízených procesů PHP-FPM stále nečinných. To znamená, že PHP-FPM je vždy nastaven na maximální objem zdrojů serveru bez ohledu na aktuální provoz. Nečinný proces čeká na špičky provozu a reaguje okamžitě. Nemusíte čekat, až pm vytvoří podřízené procesy, a pak je ukončí, jakmile vyprší období pm.process_idle_timeout. Nastavil jsem velmi vysokou hodnotu pro pm.max_requests, protože to je pracovní server bez úniků paměti v PHP. Můžete nastavit pm.max_requests = 0 se static, pokud máte úplnou důvěru v existující a budoucí PHP skripty. Ale je lepší skripty v průběhu času restartovat. Nastavte velké číslo požadavků, protože chceme se vyhnout zbytečným nákladům pm. Například alespoň pm.max_requests = 1000 — v závislosti na množství pm.max_children a počtu požadavků za sekundu.

Na snímku obrazovky je ukázán příkaz Linux top, filtrováno podle u (uživatel) a názvu uživatele PHP-FPM. Zobrazeno pouze prvních 50 nebo tak nějak procesů (přesně jsem nepočítal), ale v podstatě top ukazuje top statistiky, které se umisťují do okna terminálu. V tomto případě se řadí podle % CPU (%CPU). Chcete-li zobrazit všech 100 procesů PHP-FPM, spusťte příkaz:

top -bn1 | grep php-fpm

Kdy použít pm ondemand a dynamic

Pokud použijete pm dynamic, objevují se podobné chyby:

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

Zkuste změnit parametr, chyba neodejde, jak je popsáno v tomto příspěvku na Serverfault. V tomto případě byla hodnota pm.min příliš malá, a protože webový provoz se výrazně mění a má vysoké špičky a hluboké poklesy, je obtížné adekvátně nastavit pm dynamic. Obvykle se používá pm ondemand, jak je doporučeno v tomtéž příspěvku. Ale to je ještě horší, neboť ondemand ukončuje nečinné procesy na nulu, když je málo provozu nebo vůbec žádný, a nakonec se budete stále potýkat s náklady při změně provozu. Pokud samozřejmě nenastavíte obrovský timeout. A pak je lepší použít pm.static + vysoké číslo pm.max_requests.

PM dynamic a zejména ondemand mohou být užitečné, pokud máte více PHP-FPM poolů. Například hostíte několik cPanel účtů nebo několik webových stránek v různých poolech. Mám server, kde je, dejme tomu, více než 100 cPanel účtů a přibližně 200 domén, a pm.static nebo dokonce dynamic by mě nezachránilo. Tady potřebujete pouze ondemand, neboť více než dvě třetiny webových stránek dostávají málo provozu nebo vůbec žádný, a s ondemand všechny podřízené procesy spadnou, což nám ušetří spoustu paměti! Naštěstí si toho vývojáři cPanel všimli a nastavili výchozí hodnotu ondemand. Dříve, když byla výchozí hodnota dynamic, PHP-FPM vůbec nebyl vhodný pro vytížené sdílené servery. Mnozí používali suPHP, protože pm dynamic spotřebovával paměť i při nečinných poolech a účtech cPanel PHP-FPM. Pravděpodobně, pokud máte dobrý provoz, nebudete hostovat na serveru s velkým počtem PHP-FPM poolů (sdílený hosting).

Závěr

Pokud používáte PHP-FPM a máte vážný provoz, správci procesů ondemand a dynamic pro PHP-FPM omezují propustnost kvůli inherentním nákladům. Prozkoumejte svůj systém a nastavte procesy PHP-FPM podle maximální kapacity serveru. Nejprve nastavte pm.max_children v závislosti na maximálním využití pm dynamic nebo ondemand, a poté tuto hodnotu zvyšte na úroveň, kde paměť a procesor budou fungovat bez nadměrného zatížení. Všimnete si, že s pm static, když máte všechno uložené v paměti, budou špičky provozu v průběhu času způsobovat méně špiček pro procesor, a průměrná zatížení serveru a procesoru se vyrovnají. Průměrná velikost procesu PHP-FPM závisí na webovém serveru a vyžaduje ruční nastavení, proto jsou více automatizovaní správci procesů — dynamic a ondemand — populárnější. Doufám, že byl článek užitečný.

UPD Přidána benchmarková tabulka ab. Pokud jsou procesy PHP-FPM v paměti, výkon se zvyšuje díky spotřebě paměti, kde sedí a čekají. Najděte si optimální řešení.

Zdroj: habr.com