Agordo de PHP-FPM: uzu pm static por maksimuma rendimento

Neredaktita versio de ĉi tiu artikolo estis origine publikigita sur haydenjames.io kaj publikigita ĉi tie kun ŝia permeso la verkisto.

Mi rakontos al vi mallonge la plej bonan manieron agordi PHP-FPM por pliigi trafluon, redukti latencian kaj uzi CPU kaj memoron pli konsekvence. Defaŭlte, la PM (procezmanaĝero) linio en PHP-FPM estas dinamika, kaj se vi ne havas sufiĉe da memoro, tiam estas pli bone instali ondemand. Ni komparu 2 kontrolopciojn bazitajn sur la php.net-dokumentado kaj vidu kiel mia plej ŝatata diferencas de ili statika pm por alta volumena trafiko:

pm = dinamika — la nombro da infanaj procezoj estas agordita dinamike surbaze de la sekvaj direktivoj: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand - procezoj estas kreitaj laŭpeto (kontraste al dinamika kreado, kiam pm.start_servers estas lanĉitaj kiam la servo komenciĝas).
pm = statika — la nombro da infanaj procezoj estas fiksita kaj estas indikita per la parametro pm.max_infanoj.

Por detaloj, vidu kompleta listo de tutmondaj direktivoj php-fpm.conf.

Similecoj inter la PHP-FPM procezmanaĝero kaj la CPU-frekvenca regilo

Ĉi tio eble ŝajnas ekstertema, sed mi ligos ĉi tion al la temo de PHP-FPM-agordo. Kiu ne spertis malrapidiĝon de procesoro almenaŭ unufoje - sur tekkomputilo, virtuala maŝino aŭ dediĉita servilo? Ĉu vi memoras CPU-frekvencan skalon? Ĉi tiuj opcioj disponeblas por nix kaj Vindozo povas plibonigi sisteman rendimenton kaj respondecon ŝanĝante la procesoran akcelilon de ondemand sur agado*. Ĉi-foje, ni komparu la priskribojn kaj rigardu la similecojn:

guberniestro=ondemand — dinamika skalo de procesoro-frekvenco depende de la nuna ŝarĝo. Rapide saltas al maksimuma frekvenco kaj tiam reduktas ĝin kiam periodoj de neaktiveco pliiĝas.
guberniestro=konservativulo= dinamika frekvenca skalo depende de la nuna ŝarĝo. Pliigas kaj malpliigas frekvencon pli glate ol laŭpeto.
Governor = agado — ofteco estas ĉiam maksimuma.

Por detaloj, vidu plena listo de procesoraj frekvencaj reguligparametroj.

Vidu la similecojn? Mi volis montri ĉi tiun komparon por konvinki vin, ke estas plej bone uzi pm statika por PHP-FPM.

Por la parametro de reguligisto de procesoro elfaro helpas sekure pliigi rendimenton ĉar ĝi estas preskaŭ tute dependa de la CPU-limo de la servilo. Krom ĉi tio, kompreneble, estas ankaŭ faktoroj kiel temperaturo, kuirilaro (en tekkomputilo) kaj aliaj kromefikoj de konstante funkcii la procesoron ĉe 100%. La agordo de rendimento certigas la plej rapidan agadon de procesoro. Legu, ekzemple, pri force_turbo parametro en Raspberry Pikun kiu la RPi-panelo uzos la reguligilon elfaro, kie la agado-plibonigo estos pli rimarkebla pro la malalta CPU-horloĝrapideco.

Uzante pm static por atingi maksimuman servilan rendimenton

Opcio PHP-FPM pm statika grandparte dependas de la libera memoro sur la servilo. Se la memoro estas malalta, estas pli bone elekti ondemand aŭ dinamika. Aliflanke, se vi havas memoron, vi povas eviti la PHP-procezan administranton superkoste fiksante pm statika al la maksimuma servila kapacito. Alivorte, se ĉio estas bone kalkulita, vi devas establi pm.statika al la maksimuma volumeno de PHP-FPM-procezoj kiuj povas esti efektivigitaj, sen krei problemojn kun malalta memoro aŭ kaŝmemoro. Sed ne tiom alta ke ĝi superfortas la procesorojn kaj amasigas amason da PHP-FPM-operacioj atendantaj esti efektivigitaj..

En la supra ekrankopio, la servilo havas pm = statika kaj pm.max_infanoj = 100, kaj ĉi tio okupas proksimume 10 GB el la disponeblaj 32. Atentu la elstarigitajn kolumnojn, ĉio estas klara ĉi tie. En ĉi tiu ekrankopio estis proksimume 200 aktivaj uzantoj (pli ol 60 sekundoj) en Google Analytics. Je ĉi tiu nivelo, proksimume 70% de PHP-FPM infanprocezoj ankoraŭ estas neaktivaj. Ĉi tio signifas, ke PHP-FPM ĉiam estas agordita al la maksimuma kvanto de servilaj rimedoj sendepende de la nuna trafiko. Neaktiva procezo atendas trafikpintojn kaj respondas tuj. Vi ne devas atendi ĝis pm kreos infanajn procezojn kaj poste finos ilin kiam la periodo eksvalidiĝas pm.process_idle_timeout. Mi starigis la valoron al tre alta pm.max_petojĉar ĉi tio estas funkcianta servilo sen memorfuĝoj en PHP. Vi povas instali pm.max_petoj = 0 kun statika se vi estas tute certa pri ekzistantaj kaj estontaj PHP-skriptoj. Sed estas pli bone refari la skriptojn kun la tempo. Agordu grandan nombron da petoj, ĉar ni volas eviti nenecesajn pm-kostojn. Ekzemple, almenaŭ pm.max_petoj = 1000 - depende de kvanto pm.max_infanoj kaj la nombro da petoj por sekundo.

La ekrankopio montras la komandon Linukso supro, filtrita per u (uzanto) kaj PHP-FPM uzantnomo. Nur la unuaj 50 aŭ pli da procezoj estas montritaj (mi ne precize kalkulis), sed esence supro montras la suprajn statistikojn kiuj konvenas en la fina fenestro. Ĉi-kaze ordigita laŭ % CPU (%CPU). Por vidi ĉiujn 100 PHP-FPM-procezojn, rulu la komandon:

top -bn1 | grep php-fpm

Kiam uzi pm laŭpeta kaj dinamika

Se vi uzas pm dinamika, eraroj kiel ĉi okazas:

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

Provu ŝanĝi la parametron, la eraro ne malaperos, kiel priskribita en ĉi tiu afiŝo pri Serverfault. En ĉi tiu kazo, la valoro pm.min estis tro malgranda, kaj ĉar interreta trafiko tiom varias kaj havas altajn pintojn kaj profundajn valojn, estas malfacile adekvate ĝustigi pm. dinamika. Kutime estas uzata pm ondemand, kiel konsilite en la sama afiŝo. Sed ĉi tio estas eĉ pli malbona, ĉar ondemand ĉesigas neaktivajn procezojn al nulo kiam estas malmulte da aŭ neniu trafiko, kaj vi ankoraŭ finiĝos kun la ŝarĝo de ŝanĝiĝado de trafiko. Krom se, kompreneble, vi fiksas grandegan atendotempon. Kaj tiam estas pli bone uzi pm.statika + alta nombro pm.max_petoj.

PM dinamika kaj precipe ondemand Povas esti utila se vi havas plurajn PHP-FPM-naĝejojn. Ekzemple, vi gastigas plurajn cPanel-kontojn aŭ plurajn retejojn en malsamaj naĝejoj. Mi havas servilon kun, ekzemple, 100+ cpanel-kontoj kaj ĉirkaŭ 200 domajnoj, kaj pm.static aŭ eĉ dinamika ne savus min. Ĉio, kion vi bezonas ĉi tie, estas ondemand, Post ĉio, pli ol du trionoj de retejoj ricevas malmulte aŭ neniun trafikon, kaj kun ondemand ĉiuj infanaj procezoj defalos, kio ŝparos al ni multe da memoro! Feliĉe, la programistoj de cPanel rimarkis tion kaj starigis la valoron defaŭlte ondemand. Antaŭe, kiam la defaŭlto estis dinamika, PHP-FPM tute ne taŭgas por okupataj komunaj serviloj. Multaj uzis suPHP, ĉar pm dinamika konsumis memoron eĉ kun neaktivaj naĝejoj kaj cPanel PHP-FPM-kontoj. Plej verŝajne, se la trafiko estas bona, vi ne estos gastigita sur servilo kun granda nombro da PHP-FPM-naĝejoj (komuna gastigado).

konkludo

Se vi uzas PHP-FPM kaj via trafiko estas peza, procezadministrantoj ondemand и dinamika por PHP-FPM estos limigita trairo pro ilia eneca superkosto. Komprenu vian sistemon kaj agordu PHP-FPM-procezojn laŭ la maksimuma servila kapablo. Unua aro pm.max_infanoj depende de maksimuma pm-uzo dinamika aŭ ondemand, kaj tiam pliigu ĉi tiun valoron al nivelo kie la memoro kaj procesoro funkcios sen esti troŝarĝitaj. Vi rimarkos tion kun pm statika, ĉar vi havas ĉion en memoro, trafikpikiloj kaŭzos malpli da CPU-pikoj laŭlonge de la tempo, kaj serviloj kaj CPU-ŝarĝaj mezumoj ebeniĝos. La averaĝa PHP-FPM-proceza grandeco dependas de la retservilo kaj postulas manan agordon, do pli aŭtomatigitaj procezadministrantoj estas dinamika и ondemand - pli populara. Mi esperas, ke la artikolo estis utila.

DUP Aldonita benchmark-diagramo ab. Se PHP-FPM-procezoj estas en memoro, rendimento pliiĝas koste de memorkonsumo kie ili sidas kaj atendas. Trovu la plej bonan elekton por vi mem.

fonto: www.habr.com