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

Neupravená verze tohoto článku byla původně publikována dne haydenjames.io a s jejím svolením zde zveřejněny autor.

Řeknu vám ve zkratce, jak nejlépe nakonfigurovat PHP-FPM pro zvýšení propustnosti, snížení latence a konzistentnější využití CPU a paměti. Ve výchozím nastavení je řádek PM (správce procesů) v PHP-FPM dynamický, a pokud nemáte dostatek paměti, pak je lepší nainstalovat ondemand. Porovnejme 2 možnosti ovládání založené na dokumentaci php.net a uvidíme, jak se od nich liší můj oblíbený statický odpoledne pro velký provoz:

pm = dynamický — počet podřízených procesů je konfigurován dynamicky na základě následujících direktiv: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = na vyžádání - procesy jsou vytvářeny na vyžádání (na rozdíl od dynamického vytváření, kdy se pm.start_servers spouští při startu služby).
pm = statický — počet podřízených procesů je pevný a je indikován parametrem pm.max_children.

Podrobnosti viz kompletní seznam globálních direktiv php-fpm.conf.

Podobnosti mezi správcem procesů PHP-FPM a řadičem frekvence CPU

Může se to zdát mimo téma, ale spojím to s tématem konfigurace PHP-FPM. Kdo alespoň jednou nezažil zpomalení procesoru – na notebooku, virtuálním počítači nebo dedikovaném serveru. Pamatujete na škálování frekvence CPU? Tyto možnosti jsou k dispozici pro nix a Windows mohou zlepšit výkon a odezvu systému změnou nastavení škrticí klapky procesoru ondemand na výkon*. Tentokrát porovnejme popisy a podívejme se na podobnosti:

guvernér=na vyžádání — dynamické škálování frekvence procesoru v závislosti na aktuální zátěži. Rychle přeskočí na maximální frekvenci a poté ji sníží, když se zvýší doba nečinnosti.
guvernér=konzervativní= dynamické frekvenční škálování v závislosti na aktuální zátěži. Zvyšuje a snižuje frekvenci plynuleji než na vyžádání.
Guvernér = výkon — frekvence je vždy maximální.

Podrobnosti viz úplný seznam parametrů regulátoru frekvence procesoru.

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

Pro parametr regulátoru procesoru výkon pomáhá bezpečně zvýšit výkon, protože je téměř zcela závislý na limitu CPU serveru. Kromě toho jsou tu samozřejmě i faktory jako teplota, nabití baterie (v notebooku) a další vedlejší efekty neustálého běhu procesoru na 100 %. Nastavení výkonu zajišťuje nejrychlejší výkon procesoru. Přečtěte si například o parametr force_turbo v Raspberry Pi, se kterým bude RPi panel používat regulátor výkon, kde bude zlepšení výkonu znatelnější díky nízké frekvenci procesoru.

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

Možnost PHP-FPM pm statické do značné míry závisí na volné paměti na serveru. Pokud je paměť málo, je lepší vybrat ondemand nebo dynamický. Na druhou stranu, pokud máte paměť, můžete se vyhnout režii správce procesů PHP nastavením pm statický na maximální kapacitu serveru. Jinými slovy, pokud je vše dobře spočítáno, je třeba stanovit pm.statický na maximální objem procesů PHP-FPM, které lze spustit, bez vytváření problémů s nízkou pamětí nebo mezipamětí. Ale ne tak vysoko, aby to zahltilo procesory a nahromadilo spoustu PHP-FPM operací čekajících na provedení.

Na výše uvedeném snímku obrazovky má server pm = statické a pm.max_children = 100, a to zabírá přibližně 10 GB z dostupných 32. Pozor na zvýrazněné sloupce, zde je vše jasné. Na tomto snímku obrazovky bylo přibližně 200 aktivních uživatelů (více než 60 sekund) v Google Analytics. Na 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 nastaveno na maximální množství serverových prostředků bez ohledu na aktuální provoz. Nečinný proces čeká na dopravní špičky a okamžitě reaguje. Nemusíte čekat pm vytvoří podřízené procesy a poté je ukončí, když období vyprší pm.process_idle_timeout. Hodnotu jsem nastavil na velmi vysokou pm.max_requestsprotože toto je funkční server bez úniků paměti v PHP. Můžete nainstalovat pm.max_requests = 0 se statickým, pokud jste si zcela jisti stávajícími a budoucími skripty PHP. Ale je lepší skripty po čase znovu spustit. Nastavte velký počet požadavků, protože se chceme vyhnout zbytečným nákladům na pm. Například alespoň pm.max_requests = 1000 - v závislosti na množství pm.max_children a počet požadavků za sekundu.

Snímek obrazovky ukazuje příkaz Linux top, filtrováno podle u (uživatele) a uživatelského jména PHP-FPM. Je zobrazeno pouze prvních asi 50 procesů (nepočítal jsem přesně), ale v podstatě top zobrazuje nejlepší statistiky, které se vejdou do okna terminálu. V tomto případě seřazeno 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 dynamický, dochází k takovýmto chybám:

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 nezmizí, jako popsané v tomto příspěvku na Serverfault. V tomto případě byla hodnota pm.min příliš malá, a protože webový provoz se velmi liší a má vysoké vrcholy a hluboká údolí, je obtížné odpovídajícím způsobem upravit pm dynamický. Obvykle se používá pm ondemand, jak bylo doporučeno ve stejném příspěvku. Ale to je ještě horší, protože ondemand ukončí nečinné procesy na nulu, když je provoz malý nebo žádný, a stále budete mít režii na změnu provozu. Pokud si ovšem nenastavíte obrovskou čekací dobu. A pak je lepší použít pm.statický + vysoké číslo pm.max_requests.

PM dynamický a zejména ondemand může se hodit, pokud máte více fondů PHP-FPM. Hostujete například více účtů cPanel nebo více webových stránek v různých fondech. Mám server s řekněme 100+ účty cpanel a asi 200 doménami a pm.static nebo dokonce dynamické by mě nezachránily. Vše, co potřebujete, je zde ondemandKoneckonců, více než dvě třetiny webových stránek mají malý nebo žádný provoz ondemand všechny podřízené procesy odpadnou, což nám ušetří spoustu paměti! Naštěstí si toho všimli vývojáři cPanel a nastavili hodnotu na výchozí ondemand. Dříve, když výchozí bylo dynamický, PHP-FPM vůbec nebylo vhodné pro vytížené sdílené servery. Mnozí využili suPHP, protože pm dynamický spotřebovaná paměť i s nečinnými fondy a účty cPanel PHP-FPM. Pokud je provoz dobrý, s největší pravděpodobností nebudete hostováni na serveru s velkým počtem fondů PHP-FPM (sdílený hosting).

Závěr

Pokud používáte PHP-FPM a váš provoz je silný, manažeři procesů ondemand и dynamický pro PHP-FPM bude omezená propustnost kvůli jejich přirozené režii. Pochopte svůj systém a nakonfigurujte procesy PHP-FPM podle maximální kapacity serveru. První sada pm.max_children v závislosti na maximálním využití pm dynamický nebo ondemanda poté tuto hodnotu zvyšte na úroveň, kdy paměť a procesor budou pracovat bez přetížení. Všimnete si toho s pm statické, protože máte vše v paměti, provozní špičky způsobí v průběhu času méně špiček CPU a průměrné zatížení serveru a CPU se vyrovná. Průměrná velikost procesu PHP-FPM závisí na webovém serveru a vyžaduje manuální konfiguraci, takže jsou více automatizovaní manažeři procesů dynamický и ondemand - populárnější. Doufám, že článek byl užitečný.

UPD Přidán srovnávací graf ab. Pokud jsou procesy PHP-FPM v paměti, zvyšuje se výkon na úkor spotřeby paměti, kde sedí a čekají. Najděte si pro sebe tu nejlepší možnost.

Zdroj: www.habr.com