Konfigurimi PHP-FPM: përdorni pm static për performancë maksimale

Një version i pa redaktuar i këtij artikulli u botua fillimisht në haydenjames.io dhe botuar këtu me lejen e saj autori.

Unë do t'ju tregoj me pak fjalë se si të konfiguroni më mirë PHP-FPM për të rritur xhiron, për të zvogëluar vonesën dhe për të përdorur CPU dhe memorie në mënyrë më të qëndrueshme. Si parazgjedhje, linja PM (menaxheri i procesit) në PHP-FPM është dinamik, dhe nëse nuk keni memorie të mjaftueshme, atëherë është më mirë ta instaloni OnDemand. Le të krahasojmë 2 opsione kontrolli bazuar në dokumentacionin php.net dhe të shohim se si ndryshon e preferuara ime prej tyre i pandryshueshëm pm për trafik me volum të lartë:

pm = dinamike — numri i proceseve të fëmijëve është konfiguruar në mënyrë dinamike bazuar në direktivat e mëposhtme: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = me kërkesë - proceset krijohen sipas kërkesës (në krahasim me krijimin dinamik, kur pm.start_servers hapen kur shërbimi fillon).
pm = statike — numri i proceseve të fëmijëve është fiks dhe tregohet nga parametri pm.max_fëmijët.

Për detaje, shihni lista e plotë e direktivave globale php-fpm.conf.

Ngjashmëritë midis menaxherit të procesit PHP-FPM dhe kontrolluesit të frekuencës së CPU

Kjo mund të duket jashtë temës, por unë do ta lidh këtë me temën e konfigurimit të PHP-FPM. Kush nuk ka përjetuar një ngadalësim të procesorit të paktën një herë - në një laptop, makinë virtuale ose server të dedikuar. E mbani mend shkallën e frekuencës së CPU-së? Këto opsione janë të disponueshme për nix dhe Windows mund të përmirësojnë performancën dhe reagimin e sistemit duke ndryshuar cilësimin e mbytjes së procesorit nga OnDemand mbi performanca*. Këtë herë, le të krahasojmë përshkrimet dhe të shohim ngjashmëritë:

guvernator=kërkoj — shkallëzimi dinamik i frekuencës së procesorit në varësi të ngarkesës aktuale. Kërcen me shpejtësi në frekuencën maksimale dhe më pas e redukton me rritjen e periudhave të pasivitetit.
guvernator=konservator= shkallëzimi dinamik i frekuencës në varësi të ngarkesës aktuale. Rrit dhe ul frekuencën më lehtë sesa me kërkesë.
Guvernator = performancë — Frekuenca është gjithmonë maksimale.

Për detaje, shihni lista e plotë e parametrave të rregullatorit të frekuencës së procesorit.

Shihni ngjashmëritë? Doja të tregoja këtë krahasim për t'ju bindur se është më mirë ta përdorni pm statike për PHP-FPM.

Për parametrin e rregullatorit të procesorit performanca ndihmon në rritjen e sigurtë të performancës sepse varet pothuajse tërësisht nga kufiri i CPU-së së serverit. Përveç kësaj, natyrisht, ka edhe faktorë të tillë si temperatura, ngarkimi i baterisë (në një laptop) dhe efekte të tjera anësore të funksionimit të vazhdueshëm të procesorit në 100%. Cilësimi i performancës siguron performancën më të shpejtë të procesorit. Lexoni, për shembull, rreth Parametri force_turbo në Raspberry Pime të cilin paneli RPi do të përdorë rregullatorin performanca, ku përmirësimi i performancës do të jetë më i dukshëm për shkak të shpejtësisë së ulët të orës së CPU-së.

Përdorimi i pm static për të arritur performancën maksimale të serverit

Opsioni PHP-FPM pm statike në masë të madhe varet nga memoria e lirë në server. Nëse memoria është e ulët, është më mirë të zgjidhni OnDemand ose dinamik. Nga ana tjetër, nëse keni memorie, mund të shmangni ngarkesat e menaxherit të procesit PHP duke vendosur pm i pandryshueshëm në kapacitetin maksimal të serverit. Me fjalë të tjera, nëse gjithçka llogaritet mirë, duhet të vendosni pm.statike në vëllimin maksimal të proceseve PHP-FPM që mund të ekzekutohen, pa krijuar probleme me memorie të ulët ose cache. Por jo aq e lartë sa të mbingarkojë procesorët dhe të grumbullojë një sërë operacionesh PHP-FPM që presin të ekzekutohen.

Në pamjen e mësipërme, serveri ka pm = statike dhe pm.max_fëmijë = 100, dhe kjo kërkon afërsisht 10 GB nga 32 të disponueshme. Kushtojini vëmendje kolonave të theksuara, gjithçka është e qartë këtu. Në këtë pamje ekrani kishte afërsisht 200 përdorues aktivë (më shumë se 60 sekonda) në Google Analytics. Në këtë nivel, afërsisht 70% e proceseve të fëmijëve PHP-FPM janë ende të papunë. Kjo do të thotë që PHP-FPM është vendosur gjithmonë në sasinë maksimale të burimeve të serverit, pavarësisht nga trafiku aktual. Një proces i papunë pret për kulmin e trafikut dhe përgjigjet menjëherë. Ju nuk duhet të prisni derisa pm do të krijojë procese të fëmijëve dhe më pas do t'i përfundojë ato kur të përfundojë periudha pm.process_idle_timeout. E vendosa vlerën në shumë të lartë pm.max_kërkesatsepse ky është një server që funksionon pa rrjedhje memorie në PHP. Ju mund të instaloni pm.max_kërkesat = 0 me static nëse jeni plotësisht të sigurt në skriptet ekzistuese dhe të ardhshme PHP. Por është më mirë që të riprodhohen skenarët me kalimin e kohës. Vendosni një numër të madh kërkesash, sepse duam të shmangim kostot e panevojshme të pm. Për shembull, të paktën pm.max_kërkesat = 1000 - në varësi të sasisë pm.max_fëmijët dhe numrin e kërkesave për sekondë.

Pamja e ekranit tregon komandën Linux në krye, filtruar nga u (përdoruesi) dhe emri i përdoruesit PHP-FPM. Tregohen vetëm rreth 50 proceset e para (nuk i numërova saktësisht), por në thelb në krye tregon statistikat kryesore që përshtaten në dritaren e terminalit. Në këtë rast renditet sipas % CPU (%CPU). Për të parë të gjitha 100 proceset PHP-FPM, ekzekutoni komandën:

top -bn1 | grep php-fpm

Kur të përdoret pm ondemand dhe dinamike

Nëse përdorni pm dinamik, ndodhin gabime si ky:

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

Provoni të ndryshoni parametrin, gabimi nuk do të largohet, si përshkruar në këtë postim në Serverfault. Në këtë rast, vlera pm.min ishte shumë e vogël, dhe meqenëse trafiku në ueb ndryshon kaq shumë dhe ka maja të larta dhe lugina të thella, është e vështirë të rregullohet në mënyrë adekuate pm dinamik. Zakonisht përdoret pm OnDemand, siç këshillohet në të njëjtin postim. Por kjo është edhe më keq, sepse OnDemand përfundon proceset e papunë në zero kur ka pak ose aspak trafik, dhe ju ende do të përfundoni me shpenzimet e përgjithshme të ndryshimit të trafikut. Nëse, sigurisht, nuk vendosni një kohë të madhe pritjeje. Dhe atëherë është më mirë të përdoret pm.statike + numër i lartë pm.max_kërkesat.

PM dinamik dhe posaçërisht OnDemand mund të jetë i dobishëm nëse keni grupe të shumta PHP-FPM. Për shembull, ju pret llogari të shumta cPanel ose uebfaqe të shumta në pishina të ndryshme. Unë kam një server me, të themi, 100+ llogari cpanel dhe rreth 200 domene, dhe pm.static apo edhe dinamik nuk do të më shpëtonte. Gjithçka që ju nevojitet këtu është OnDemand, në fund të fundit, më shumë se dy të tretat e faqeve të internetit marrin pak ose aspak trafik, dhe me OnDemand të gjitha proceset e fëmijëve do të bien, gjë që do të na kursejë shumë memorie! Për fat të mirë, zhvilluesit e cPanel e vunë re këtë dhe vendosën vlerën në parazgjedhje OnDemand. Më parë, kur parazgjedhja ishte dinamik, PHP-FPM nuk ishte fare i përshtatshëm për serverët e përbashkët të zënë. Shumë kanë përdorur suPHP, sepse pm dinamik memorie të konsumuar edhe me grupe boshe dhe llogari të cPanel PHP-FPM. Me shumë mundësi, nëse trafiku është i mirë, nuk do të strehoheni në një server me një numër të madh të pishinave PHP-FPM (strehimi i përbashkët).

Përfundim

Nëse jeni duke përdorur PHP-FPM dhe trafiku juaj është i rëndë, menaxherët e procesit OnDemand и dinamik për PHP-FPM do të jetë i kufizuar për shkak të shpenzimeve të tyre të përgjithshme. Kuptoni sistemin tuaj dhe konfiguroni proceset PHP-FPM sipas kapacitetit maksimal të serverit. Seti i parë pm.max_fëmijët në varësi të përdorimit maksimal të pm dinamik ose OnDemand, dhe më pas rrisni këtë vlerë në një nivel ku memoria dhe procesori do të punojnë pa u mbingarkuar. Do ta vini re se me pm statike, meqenëse keni gjithçka në memorie, rritjet e trafikut do të shkaktojnë më pak rritje të CPU-së me kalimin e kohës dhe mesataret e ngarkesës së serverit dhe CPU-së do të nivelizohen. Madhësia mesatare e procesit PHP-FPM varet nga serveri i uebit dhe kërkon konfigurim manual, kështu që menaxherët më të automatizuar të procesit janë dinamik и OnDemand - më popullor. Shpresoj se artikulli ishte i dobishëm.

DUP Grafiku i standardeve të shtuar ab. Nëse proceset PHP-FPM janë në memorie, performanca rritet në kurriz të konsumit të memories ku ata ulen dhe presin. Gjeni opsionin më të mirë për veten tuaj.

Burimi: www.habr.com