PHP-FPM konfigurazioa: erabili pm static errendimendu handiena lortzeko

PHP-FPM konfigurazioa: erabili pm static errendimendu handiena lortzeko

Artikulu honen bertsio editatu gabeko bat argitaratu zen jatorriz haydenjames.io eta hemen argitaratu zuen bere baimenarekin egilea.

Hitz gutxitan esango dizut PHP-FPM nola konfiguratu onena errendimendua handitzeko, latentzia murrizteko eta CPU eta memoria modu koherenteagoan erabiltzeko. Lehenespenez, PM (prozesuen kudeatzailea) lerroa da PHP-FPM-n dinamikoa, eta memoria nahikoa ez baduzu, hobe da instalatzea eskariaren arabera. Konpara ditzagun php.net-eko dokumentazioan oinarritutako 2 kontrol-aukera eta ikus ditzagun nire gogokoena haietatik nola desberdintzen den estatiko pm bolumen handiko trafikorako:

pm = dinamikoa β€” prozesu seme-alaben kopurua dinamikoki konfiguratzen da jarraibide hauetan oinarrituta: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = demanda - prozesuak eskaeraren arabera sortzen dira (sorkuntza dinamikoaren aurka, pm.start_servers zerbitzua hasten denean abiarazten direnean).
pm = estatikoa β€” Haur prozesuen kopurua finkoa da eta parametroak adierazten du pm.max_haurrak.

Xehetasunetarako, ikus Zuzentarau globalen zerrenda osoa php-fpm.conf.

PHP-FPM prozesu-kudeatzailearen eta PUZaren maiztasun-kontrolatzailearen arteko antzekotasunak

Gaiz kanpokoa dirudi, baina PHP-FPM konfigurazioaren gaiarekin lotuko dut. Nork ez duen gutxienez behin prozesadorearen moteltzerik izan - ordenagailu eramangarri batean, makina birtualean edo zerbitzari dedikatu batean. Gogoratzen al duzu CPUaren maiztasunaren eskalatzea? Aukera hauek eskuragarri daude nix-ek eta Windows-ek sistemaren errendimendua eta sentikortasuna hobetu ditzakete prozesadorearen abiaduraren ezarpena aldatuz eskariaren arabera on errendimendua*. Oraingoan, aldera ditzagun deskribapenak eta ikus ditzagun antzekotasunak:

gobernador=eskaera β€” Prozesadorearen maiztasunaren eskalatze dinamikoa, uneko kargaren arabera. Bizkor jauzi egiten du gehieneko maiztasunera eta gero murrizten du inaktibitate-aldiak handitu ahala.
gobernadore=kontserbadorea= maiztasun-eskala dinamikoa uneko kargaren arabera. Maiztasuna handitu eta murrizten du, eskaria baino arinago.
Governor = performance β€” maiztasuna beti da maximoa.

Xehetasunetarako, ikus prozesadorearen maiztasun erregulatzaileen parametroen zerrenda osoa.

Ikusi antzekotasunak? Konparaketa hau erakutsi nahi izan dizut erabiltzea egokiena dela sinetsarazteko pm estatikoa PHP-FPMrako.

Prozesadore erregulatzaile parametrorako errendimendu errendimendua segurtasunez handitzen laguntzen du zerbitzariaren CPU mugaren ia erabat menpe dagoelako. Honetaz gain, noski, tenperatura, bateriaren karga (ordenagailu eramangarri batean) eta prozesadorea etengabe exekutatzeko beste albo-ondorio batzuk ere badaude. Errendimendu ezarpenak prozesadorearen errendimendu azkarrena bermatzen du. Irakurri, adibidez, buruz force_turbo parametroa Raspberry Pi-n, eta horrekin RPi panelak erregulatzailea erabiliko du errendimendu, non errendimenduaren hobekuntza nabarmenagoa izango den PUZaren erlojuaren abiadura baxuaren ondorioz.

pm static erabiltzea zerbitzariaren errendimendu maximoa lortzeko

PHP-FPM aukera pm estatikoa zerbitzariaren memoria librearen araberakoa da neurri handi batean. Memoria baxua bada, hobe da aukeratzea eskariaren arabera edo dinamikoa. Bestalde, memoria baduzu, PHP prozesu-kudeatzailea saihestu dezakezu pm ezarriz estatiko zerbitzariaren gehienezko ahalmenera. Beste era batera esanda, dena ondo kalkulatzen bada, ezarri behar duzu pm.estatikoa exekutatu daitezkeen PHP-FPM prozesuen gehienezko bolumenera, memoria edo cache baxuarekin arazorik sortu gabe. Baina ez da hain altua prozesadoreak gainditzen dituela eta PHP-FPM eragiketa pila bat exekutatzeko zain..

PHP-FPM konfigurazioa: erabili pm static errendimendu handiena lortzeko

Goiko pantaila-argazkian, zerbitzariak ditu pm = estatikoa eta pm.max_children = 100, eta honek gutxi gorabehera 10 GB hartzen ditu eskuragarri dauden 32. Kontuz nabarmendutako zutabeei, dena argi dago hemen. Pantaila-argazki honetan 200 erabiltzaile aktibo zeuden gutxi gorabehera (60 segundo baino gehiago) Google Analytics-en. Maila honetan, PHP-FPM haur prozesuen % 70 gutxi gorabehera inaktibo daude oraindik. Horrek esan nahi du PHP-FPM zerbitzari-baliabideen kopuru maximoan ezartzen dela beti uneko trafikoa edozein dela ere. Inaktibo prozesu batek trafiko-gailurren itxaroten du eta berehala erantzuten du. Ez duzu arte itxaron behar pm ume-prozesuak sortuko ditu eta, ondoren, epea amaitzen denean amaituko ditu pm.prozesua_idle_timeout. Balioa oso altuan ezarri dut pm.max_requestsizan ere, funtzionatzen duen zerbitzari bat da PHPn memoria-filtraziorik ez duena. Instalatu dezakezu pm.max_requests = 0 estatikoarekin lehendik eta etorkizuneko PHP scriptetan guztiz ziur bazaude. Baina hobe da denborarekin gidoiak berriro exekutatu. Ezarri eskaera kopuru handia, beharrezkoak ez diren pm kostuak saihestu nahi ditugulako. Adibidez, behintzat pm.max_requests = 1000 - kantitatearen arabera pm.max_haurrak eta segundoko eskaera kopurua.

Pantaila-argazkiak komandoa erakusten du Linux goia, u (erabiltzailea) eta PHP-FPM erabiltzaile-izenak iragazita. Lehenengo 50 edo gehiago prozesuak baino ez dira erakusten (ez dut zehatz-mehatz zenbatu), baina funtsean goikoak terminaleko leihoan sartzen diren estatistikak erakusten ditu. Kasu honetan % CPU (%CPU) arabera ordenatuta. 100 PHP-FPM prozesu guztiak ikusteko, exekutatu komandoa:

top -bn1 | grep php-fpm

Noiz erabili pm eskaera eta dinamikoa

pm erabiltzen baduzu dinamikoa, honelako akatsak gertatzen dira:

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

Saiatu parametroa aldatzen, errorea ez da desagertuko, adibidez Serverfault-en argitalpen honetan deskribatzen da. Kasu honetan, pm.min balioa txikiegia zen, eta web trafikoa asko aldatzen denez eta gailur altuak eta haran sakonak dituenez, zaila da pm behar bezala doitzea. dinamikoa. Normalean pm erabiltzen da eskariaren arabera, mezu berean aholkatzen den bezala. Baina hau are okerragoa da, zeren eskariaren arabera Inaktibo prozesuak zerora amaitzen ditu trafiko gutxi dagoenean edo ez dagoenean, eta oraindik ere trafikoa aldatzearen kostua izango duzu. Itxaron denbora itzela ezarri ez baduzu, noski. Eta gero hobe da erabiltzea pm.estatikoa + kopuru altua pm.max_requests.

PM dinamikoa eta, bereziki, eskariaren arabera erabilgarria izan daiteke PHP-FPM igerileku anitz badituzu. Esate baterako, hainbat cPanel kontu edo hainbat webgune ostatatzen dituzu igerileku ezberdinetan. Zerbitzari bat daukat, esate baterako, 100+ cpanel kontu eta 200 domeinu inguru dituena, eta pm.static edo are dinamikoak ez ninduke salbatuko. Hemen behar duzun guztia da eskariaren arabera, azken finean, webguneen bi herenek baino gehiagok trafiko gutxi edo bat ere jasotzen dute, eta horrekin eskariaren arabera Haur prozesu guztiak eroriko dira, eta horrek memoria asko gordeko digu! Zorionez, cPanel-eko garatzaileek hori nabaritu zuten eta balioa lehenetsi zuten eskariaren arabera. Aurretik, lehenetsia zenean dinamikoa, PHP-FPM ez zen batere egokia okupatutako zerbitzari partekatuetarako. Askok erabili dute suPHP, pm dinamikoa memoria kontsumitzen du igerileku inaktiboekin eta cPanel PHP-FPM kontuekin ere. Seguruenik, trafikoa ona bada, ez zara ostatatuko PHP-FPM igerileku ugari dituen zerbitzari batean (hosting partekatua).

Ondorioa

PHP-FPM erabiltzen ari bazara eta zure trafikoa astuna bada, prozesu-kudeatzaileak eskariaren arabera ΠΈ dinamikoa PHP-FPM-rako errendimendu mugatua izango da berezko gainkostua dela eta. Ulertu zure sistema eta konfiguratu PHP-FPM prozesuak zerbitzariaren gehienezko ahalmenaren arabera. Lehenengo multzoa pm.max_haurrak pm gehienezko erabileraren arabera dinamikoa edo eskariaren arabera, eta gero balio hori handitu memoriak eta prozesadoreak gainkargatu gabe funtzionatuko duen maila bateraino. Horrekin nabarituko duzu pm estatikoa, dena memorian duzunez, trafiko-puntek denboran zehar CPU-puntu gutxiago eragingo dituzte, eta zerbitzariaren eta PUZaren kargaren batez bestekoak berdindu egingo dira. PHP-FPM prozesuen batez besteko tamaina web zerbitzariaren araberakoa da eta eskuzko konfigurazioa behar du, beraz, prozesu-kudeatzaile automatizatuagoak daude. dinamikoa ΠΈ eskariaren arabera - ezagunagoa. Espero dut artikulua erabilgarria izan dela.

DUP Erreferentzia-diagrama gehitu da ab. PHP-FPM prozesuak memorian badaude, errendimendua handitzen da memoria-kontsumoaren kontura, eserita eta itxaroten diren tokian. Aurkitu zuretzako aukerarik onena.

PHP-FPM konfigurazioa: erabili pm static errendimendu handiena lortzeko

Iturria: www.habr.com

Gehitu iruzkin berria