PHP-FPM setup: gumamit ng pm static para sa maximum na performance

Ang isang hindi na-edit na bersyon ng artikulong ito ay orihinal na nai-publish sa haydenjames.io at nai-publish dito sa kanyang pahintulot may-akda.

Sa madaling sabi, sasabihin ko sa iyo kung paano pinakamahusay na i-configure ang PHP-FPM para pataasin ang throughput, bawasan ang latency, at gamitin ang CPU at memory nang mas pare-pareho. Bilang default, ang linya ng PM (process manager) sa PHP-FPM ay dynamic, at kung wala kang sapat na memorya, mas mahusay na mag-install ondemand. Paghambingin natin ang 2 opsyon sa pagkontrol batay sa dokumentasyon ng php.net at tingnan kung paano naiiba ang paborito ko sa kanila statik pm para sa mataas na dami ng trapiko:

pm = dynamic — ang bilang ng mga proseso ng bata ay dynamic na na-configure batay sa mga sumusunod na direktiba: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand - ang mga proseso ay nilikha on demand (kumpara sa dynamic na paglikha, kapag ang pm.start_servers ay inilunsad kapag nagsimula ang serbisyo).
pm = static — ang bilang ng mga proseso ng bata ay naayos at ipinahiwatig ng parameter pm.max_children.

Para sa mga detalye, tingnan kumpletong listahan ng mga pandaigdigang direktiba php-fpm.conf.

Pagkakatulad sa pagitan ng PHP-FPM process manager at ng CPU frequency controller

Ito ay maaaring mukhang offtopic, ngunit iuugnay ko ito sa paksa ng PHP-FPM configuration. Sino ang hindi nakaranas ng paghina ng processor kahit isang beses - sa isang laptop, virtual machine o dedikadong server? Tandaan ang pag-scale ng dalas ng CPU? Ang mga opsyon na ito ay magagamit para sa nix at Windows ay maaaring mapabuti ang pagganap ng system at pagtugon sa pamamagitan ng pagbabago ng throttle setting ng processor mula sa ondemand sa pagganap*. Sa pagkakataong ito, ihambing natin ang mga paglalarawan at tingnan ang pagkakatulad:

gobernador=ondemand — dynamic na pag-scale ng dalas ng processor depende sa kasalukuyang pagkarga. Mabilis na tumalon sa pinakamataas na dalas at pagkatapos ay binabawasan ito habang tumataas ang mga panahon ng kawalan ng aktibidad.
gobernador=konserbatibo= dynamic na frequency scaling depende sa kasalukuyang load. Tumataas at binabawasan ang dalas nang mas maayos kaysa sa ondemand.
Gobernador = pagganap — ang dalas ay palaging maximum.

Para sa mga detalye, tingnan buong listahan ng mga parameter ng processor frequency regulator.

Tingnan ang pagkakatulad? Nais kong ipakita ang paghahambing na ito upang kumbinsihin ka na ito ay pinakamahusay na gamitin pm static para sa PHP-FPM.

Para sa parameter ng regulator ng processor pagganap nakakatulong na ligtas na mapataas ang performance dahil halos nakadepende ito sa limitasyon ng CPU ng server. Bilang karagdagan dito, siyempre, mayroon ding mga kadahilanan tulad ng temperatura, singil ng baterya (sa isang laptop) at iba pang mga epekto ng patuloy na pagpapatakbo ng processor sa 100%. Tinitiyak ng setting ng pagganap ang pinakamabilis na pagganap ng processor. Basahin, halimbawa, ang tungkol sa force_turbo parameter sa Raspberry Pi, kung saan gagamitin ng panel ng RPi ang regulator pagganap, kung saan ang pagpapabuti ng pagganap ay magiging mas kapansin-pansin dahil sa mababang bilis ng orasan ng CPU.

Paggamit ng pm static upang makamit ang maximum na pagganap ng server

Opsyon na PHP-FPM pm static higit sa lahat ay nakasalalay sa libreng memorya sa server. Kung mababa ang memorya, mas mahusay na pumili ondemand o dynamic. Sa kabilang banda, kung mayroon kang memorya, maiiwasan mo ang overhead ng PHP process manager sa pamamagitan ng pagtatakda ng pm statik sa pinakamataas na kapasidad ng server. Sa madaling salita, kung ang lahat ay kinakalkula nang maayos, kailangan mong magtatag pm.static sa maximum na dami ng mga prosesong PHP-FPM na maaaring isagawa, nang hindi lumilikha ng mga problema sa mababang memorya o cache. Ngunit hindi ganoon kataas na nababalot nito ang mga processor at nag-iipon ng isang grupo ng mga pagpapatakbo ng PHP-FPM na naghihintay na maisakatuparan.

Sa screenshot sa itaas, mayroon ang server pm = static at pm.max_children = 100, at ito ay tumatagal ng humigit-kumulang 10 GB mula sa magagamit na 32. Bigyang-pansin ang mga naka-highlight na column, ang lahat ay malinaw dito. Sa screenshot na ito mayroong humigit-kumulang 200 aktibong user (higit sa 60 segundo) sa Google Analytics. Sa antas na ito, humigit-kumulang 70% ng PHP-FPM na proseso ng bata ay idle pa rin. Nangangahulugan ito na palaging nakatakda ang PHP-FPM sa maximum na dami ng mga mapagkukunan ng server anuman ang kasalukuyang trapiko. Ang isang idle na proseso ay naghihintay para sa mga peak ng trapiko at agad na tumutugon. Hindi mo na kailangang maghintay hanggang pm ay lilikha ng mga proseso ng bata at pagkatapos ay wawakasan ang mga ito kapag nag-expire ang panahon pm.process_idle_timeout. Itinakda ko ang halaga sa napakataas pm.max_requestsdahil ito ay isang gumaganang server na walang memory leaks sa PHP. Maaari mong i-install pm.max_requests = 0 na may static kung ganap kang kumpiyansa sa mga umiiral at hinaharap na PHP script. Ngunit mas mahusay na muling patakbuhin ang mga script sa paglipas ng panahon. Magtakda ng malaking bilang ng mga kahilingan, dahil gusto naming maiwasan ang mga hindi kinakailangang gastos sa pm. Halimbawa, hindi bababa sa pm.max_requests = 1000 - depende sa dami pm.max_children at ang bilang ng mga kahilingan sa bawat segundo.

Ipinapakita ng screenshot ang command Linux tuktok, na-filter ng u (user) at PHP-FPM username. Tanging ang unang 50 o higit pang mga proseso ang ipinapakita (hindi ko binilang nang eksakto), ngunit mahalagang nasa itaas ay nagpapakita ng mga nangungunang istatistika na akma sa terminal window. Sa kasong ito, inayos ayon sa % CPU (%CPU). Upang makita ang lahat ng 100 PHP-FPM na proseso, patakbuhin ang command:

top -bn1 | grep php-fpm

Kailan gagamitin ang pm ondemand at dynamic

Kung gagamit ka pm dynamic, nangyayari ang mga error na tulad nito:

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

Subukang baguhin ang parameter, ang error ay hindi mawawala, tulad ng inilarawan sa post na ito sa Serverfault. Sa kasong ito, ang halaga ng pm.min ay masyadong maliit, at dahil ang trapiko sa web ay nag-iiba-iba at may matataas na mga taluktok at malalalim na lambak, mahirap ayusin ang pm nang sapat. dynamic. Usually pm ang ginagamit ondemand, gaya ng ipinapayo sa parehong post. Ngunit ito ay mas masahol pa, dahil ondemand tinatapos ang mga idle na proseso sa zero kapag kakaunti o walang trapiko, at mapupunta ka pa rin sa overhead ng pagbabago ng trapiko. Maliban kung, siyempre, nagtakda ka ng isang malaking oras ng paghihintay. At pagkatapos ay mas mahusay na gamitin pm.static + mataas na bilang pm.max_requests.

PM dynamic at lalo na ondemand maaaring magamit kung marami kang PHP-FPM pool. Halimbawa, nagho-host ka ng maraming cPanel account o maraming website sa iba't ibang pool. Mayroon akong server na may, sabihin nating, 100+ cpanel account at humigit-kumulang 200 domain, at hindi ako maililigtas ng pm.static o kahit na dynamic. Ang kailangan mo lang dito ay ondemand, pagkatapos ng lahat, higit sa dalawang-katlo ng mga website ay tumatanggap ng kaunti o walang trapiko, at may ondemand lahat ng proseso ng bata ay mahuhulog, na magliligtas sa atin ng maraming memorya! Sa kabutihang palad, napansin ito ng mga developer ng cPanel at itinakda ang halaga sa default ondemand. Dati, kapag ang default ay dynamic, PHP-FPM ay hindi angkop para sa mga abalang nakabahaging server sa lahat. Marami na ang gumamit suPHP, dahil pm dynamic naubos ang memorya kahit na may mga idle pool at cPanel PHP-FPM account. Malamang, kung maganda ang trapiko, hindi ka maho-host sa isang server na may malaking bilang ng mga PHP-FPM pool (shared hosting).

Konklusyon

Kung gumagamit ka ng PHP-FPM at mabigat ang iyong trapiko, iproseso ang mga tagapamahala ondemand и dynamic para sa PHP-FPM ay magiging limitado ang throughput dahil sa kanilang likas na overhead. Unawain ang iyong system at i-configure ang mga proseso ng PHP-FPM ayon sa maximum na kapasidad ng server. Unang set pm.max_children depende sa maximum pm usage dynamic o ondemand, at pagkatapos ay taasan ang halagang ito sa isang antas kung saan gagana ang memorya at processor nang hindi na-overload. Mapapansin mo iyon sa pm static, dahil nasa memorya mo na ang lahat, ang mga pagtaas ng trapiko ay magdudulot ng mas kaunting mga spike ng CPU sa paglipas ng panahon, at ang mga average ng pag-load ng server at CPU ay magiging level out. Ang average na laki ng proseso ng PHP-FPM ay nakasalalay sa web server at nangangailangan ng manu-manong pagsasaayos, kaya mas maraming mga awtomatikong tagapamahala ng proseso dynamic и ondemand - mas sikat. Umaasa ako na ang artikulo ay naging kapaki-pakinabang.

DUP Nagdagdag ng benchmark na tsart ab. Kung nasa memorya ang mga proseso ng PHP-FPM, tataas ang pagganap sa gastos ng pagkonsumo ng memory kung saan sila nakaupo at naghihintay. Hanapin ang pinakamahusay na pagpipilian para sa iyong sarili.

Pinagmulan: www.habr.com