Neopravená verzia článku bola pôvodne publikovaná na a publikujeme ju tu s povolením jej .
V skratke vám prerozprávam, ako najlepšie nastaviť PHP-FPM na zvýšenie priepustnosti, zníženie oneskorenia a stabilnejšie využitie procesorových zdrojov a pamäte. Predvolene má riadok PM (process manager, manažér procesov) v PHP-FPM hodnotu dynamic, a ak máte nedostatok pamäte, je lepšie nastaviť ondemand. Porovnajme 2 možnosti riadenia na základe dokumentácie php.net a pozrime sa, čím sa od seba líši moja obľúbená static pm pre vysoký objem prevádzky:
pm = dynamic — počet dieťaťských procesov sa nastavuje dynamicky na základe nasledujúcich direktív: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — procesy sa vytvárajú na požiadanie (na rozdiel od dynamického vytvárania, kde sa pm.start_servers spúšťajú pri štarte služby).
pm = static — počet dieťaťských procesov je pevne stanovený a určuje sa parametrom pm.max_children.
Podrobnosti pozri v .
Podobnosti manažéra procesu PHP-FPM s regulátorom frekvencie procesora
Môže sa to zdať ako odbočka, ale chystám sa to spojiť s témou nastavenia PHP-FPM. Kto z vás nezažil spomalenie procesora – na notebooku, virtuálnom stroji alebo dedikovanom serveri? Pamätáte si škálovanie frekvencie procesora? Tieto parametre, dostupné pre nix a Windows, môžu zvýšiť výkon a rýchlosť reakcie systému, ak změníte parameter regulátora procesora na ondemand na performance*. Tentoraz porovnajme opisy a pozrime sa na podobnosti:
Governor = ondemand — dynamické škálovanie frekvencie procesora v závislosti od aktuálnej záťaže. Náhle prechádza na maximálnu frekvenciu a potom ju znižuje, keď sa zvyšujú obdobia nečinnosti.
Governor = conservative = dynamické škálovanie frekvencie v závislosti od aktuálnej záťaže. Zvyšuje a znižuje frekvenciu plynulejšie ako ondemand.
Governor = performance — frekvencia je vždy maximálna.
Podrobnosti pozri v .
Vidíte podobnosť? Chcel som ukázať toto porovnanie, aby som vás presvedčil, že je najlepšie použiť pm static pre PHP-FPM.
Pre regulátor procesora je parameter performance pomáha bezpečne zvýšiť výkon, pretože takmer úplne závisí od limitu procesora servera. Okrem toho, samozrejme, existujú aj ďalšie faktory, ako je teplota, nabitie batérie (v notebooku) a iné vedľajšie efekty nepretržitej práce procesora na 100%. Nastavenie výkonu zabezpečuje najrýchlejšiu prácu procesora. Prečítajte si napríklad o , s ktorým panel RPi bude používať regulátor performance, kde bude zlepšenie výkonu viditeľnejšie kvôli nízkej taktovacej frekvencii CPU.
Použitie pm static na dosiahnutie maximálneho výkonu servera
Parameter PHP-FPM pm static do veľkej miery závisí od voľnej pamäte na serveri. Ak je pamäť nízka, je lepšie zvoliť ondemand alebo dynamic. Na druhej strane, ak máte dostatok pamäte, môžete sa vyhnúť zbytočným nákladom manažéra procesu PHP nastavením pm static na maximálnu kapacitu servera. Inými slovami, ak sa všetko dobre vypočíta, je potrebné nastaviť pm.static na maximálny objem procesov PHP-FPM, ktoré môžu bežať, nevyvolávajúc problémy s nedostatkom pamäte alebo cache. Ale nie tak vysoko, aby preťažili procesory a nahromadili hromadu operácií PHP-FPM čakajúcich na vykonanie.
Na screenshotu vyššie má server nastavené pm = static a pm.max_children = 100, a toto zaberá približne 10 GB z dostupných 32. Všimnite si zvýraznené stĺpce, je tu všetko jasné. Na tomto screenshotu bolo približne 200 aktívnych používateľov (viac ako 60 sekúnd) v Google Analytics. Na tejto úrovni je približne 70% podriadených procesov PHP-FPM stále nečinných. To znamená, že PHP-FPM je vždy nastavené na maximálny objem zdrojov servera bez ohľadu na aktuálny prevádzku. Nečinný proces čaká na špičky prevádzky a reaguje okamžite. Nemusíte čakať, kým pm vytvorí podriadené procesy a potom ich ukončí, keď uplynie obdobie pm.process_idle_timeout. Nastavil som veľmi vysokú hodnotu pre pm.max_requests, pretože je to pracovný server bez únikov pamäte v PHP. Môžete nastaviť pm.max_requests = 0 so static, ak si ste úplne istí existujúcimi a budúcimi PHP skriptami. Ale lepšie je reštartovať skripty v priebehu času. Nastavte vysoké číslo požiadaviek, veď chceme vyhnúť sa zbytočným nákladom pm. Napríklad aspoň pm.max_requests = 1000 — v závislosti od počtu pm.max_children a počtu požiadaviek za sekundu.
Na screenshotu je zobrazený príkaz , filtrovaná podľa u (užívateľ) a mena používateľa PHP-FPM. Zobrazené sú len prvé 50 alebo tak procesov (presne som nepočítal), ale v podstate top zobrazuje špičkové štatistiky, ktoré sú umiestnené v okne terminálu. V tomto prípade so zoradením podľa % CPU (%CPU). Ak chcete vidieť všetkých 100 procesov PHP-FPM, vykonajte príkaz:
top -bn1 | grep php-fpmKedy používať pm ondemand a dynamic
Ak sa použije pm dynamic, vznikajú 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 childrenSkúste zmeniť parameter, chyba nikam nezmizne, ako . V tomto prípade bolo hodnota pm.min príliš malé, a keďže webový traffic sa výrazne mení a má vysoké vrcholy a hlboké poklesy, je ťažké adekvátne nastaviť pm dynamic. Zvyčajne sa v týchto prípadoch používa pm ondemand, . Ale to je ešte horšie, pretože ondemand končí nečinné procesy na nulu, keď je málo alebo žiadny traffic, a nakoniec sa aj tak budete trápiť s nákladmi na zmenu trafficu. Ak samozrejme neodstránite obrovské časové oneskorenie. A potom je lepšie použiť pm.static + vysoké číslo pm.max_requests.
PM dynamic a najmä ondemand môžu byť nápomocné, ak máte viacero poolov PHP-FPM. Napríklad, ak hostíte niekoľko účet cPanel alebo niekoľko webových stránok v rôznych pooloch. Mám server, kde, povedzme, 100+ účtov cpanel a približne 200 domén, a pm.static alebo dokonca dynamic by ma nezachránili. Tu potrebujem len ondemand, pretože viac než dve tretiny webových stránok dostávajú málo trafficu alebo vôbec žiadny, a s ondemand všetky podprosesy sa odpoja, čo nám ušetrí veľa pamäte! Našťastie si toto vývojári cPanel všimli a nastavili predvolenú hodnotu ondemand. Predtým, keď bola predvolená hodnota dynamic, PHP-FPM vôbec nevyhovoval na zaťažené zdieľané servery. Mnohí používali suPHP, pretože pm dynamic spotrebovával pamäť aj pri nečinných pooloch a účtoch cPanel PHP-FPM. Pravdepodobne, pri dobrom trafficu nebudete hosťovaní na serveri s veľkým počtom poolov PHP-FPM (zdieľaný hosting).
Záver
Ak používate PHP-FPM a máte vážny traffic, manažéri procesov ondemand a dynamic pre PHP-FPM budú obmedzovať priepustnosť kvôli vlastným nákladom. Preskúmajte svoju systém a nastavte procesy PHP-FPM v súlade s maximálnou kapacitou servera. Najprv nastavte pm.max_children v závislosti od maximálneho využitia pm dynamic alebo ondemand, a potom túto hodnotu zvyšte na úroveň, kde bude pamäť a procesor fungovať bez nadmerného zaťaženia. Všimnete si, že pm static, keď máte všetko uložené v pamäti, špičky dopravy časom spôsobia menej špičiek pre procesor a priemerné hodnoty zaťaženia servera a procesora sa vyrovnajú. Priemerná veľkosť procesu PHP-FPM závisí od webového servera a vyžaduje manuálne nastavenie, takže automatizovanejšie manažéry procesov sú dynamic a ondemand — populárnejšie. Dúfam, že článok bol užitočný.
UPD Pridaný graf benchmarku . Ak sú procesy PHP-FPM v pamäti, výkon sa zvyšuje vďaka spotrebe pamäte, kde sedí a čaká. Nájdite pre seba optimálnu možnosť.
Zdroj: habr.com
