Gosod PHP-FPM: defnyddiwch pm statig ar gyfer y perfformiad mwyaf posibl

Cyhoeddwyd fersiwn heb ei olygu o'r erthygl hon yn wreiddiol ar haydenjames.io a chyhoeddir yma gyda'i chaniatad awdur.

Byddaf yn dweud wrthych yn gryno beth yw'r ffordd orau o ffurfweddu PHP-FPM i gynyddu trwybwn, lleihau hwyrni, a defnyddio CPU a chof yn fwy cyson. Yn ddiofyn, y llinell PM (rheolwr proses) yn PHP-FPM yw deinamig, ac os nad oes gennych ddigon o gof, yna mae'n well gosod ar alw. Gadewch i ni gymharu 2 opsiwn rheoli yn seiliedig ar y ddogfennaeth php.net a gweld sut mae fy ffefryn yn wahanol iddynt sefydlog pm ar gyfer traffig cyfaint uchel:

pm = deinamig - mae nifer y prosesau plant wedi'u ffurfweddu'n ddeinamig yn seiliedig ar y cyfarwyddebau canlynol: pm.max_children, gweinyddwyr pm.start,pm.min_spare_servers, gweinyddwyr pm.max_spare_spare.
pm = ondemand - mae prosesau'n cael eu creu ar alw (yn hytrach na chreu deinamig, pan fydd pm.start_servers yn cael eu lansio pan fydd y gwasanaeth yn dechrau).
pm = statig - mae nifer y prosesau plentyn yn sefydlog ac yn cael ei nodi gan y paramedr pm.max_plant.

Am fanylion, gw rhestr gyflawn o gyfarwyddebau byd-eang php-fpm.conf.

Tebygrwydd rhwng rheolwr proses PHP-FPM a rheolwr amledd y CPU

Efallai bod hyn yn ymddangos yn offtopic, ond rydw i'n mynd i gysylltu hyn â phwnc cyfluniad PHP-FPM. Pwy sydd heb brofi prosesydd yn arafu o leiaf unwaith - ar liniadur, peiriant rhithwir neu weinydd pwrpasol. Cofiwch raddio amledd CPU? Mae'r opsiynau hyn ar gael ar gyfer gall nix a Windows wella perfformiad system ac ymatebolrwydd trwy newid gosodiad sbardun y prosesydd o ar alw ar perfformiad*. Y tro hwn, gadewch i ni gymharu'r disgrifiadau ac edrych ar y tebygrwydd:

llywodraethwr=ondemand - graddio amlder prosesydd yn ddeinamig yn dibynnu ar y llwyth cyfredol. Yn neidio'n gyflym i'r amledd mwyaf ac yna'n ei leihau wrth i gyfnodau o anweithgarwch gynyddu.
llywodraethwr = ceidwadol = graddio amlder deinamig yn dibynnu ar y llwyth presennol. Yn cynyddu ac yn lleihau amlder yn fwy llyfn nag ondemand.
Llywodraethwr = perfformiad — mae amlder bob amser yn uchaf.

Am fanylion, gw rhestr lawn o baramedrau rheolydd amlder prosesydd.

Gweld y tebygrwydd? Roeddwn i eisiau dangos y gymhariaeth hon i'ch argyhoeddi mai dyma'r peth gorau i'w ddefnyddio pm sefydlog ar gyfer PHP-FPM.

Ar gyfer y paramedr rheolydd prosesydd perfformiad yn helpu i gynyddu perfformiad yn ddiogel oherwydd ei fod bron yn gyfan gwbl ddibynnol ar derfyn CPU y gweinydd. Yn ogystal â hyn, wrth gwrs, mae yna hefyd ffactorau megis tymheredd, tâl batri (mewn gliniadur) a sgîl-effeithiau eraill o redeg y prosesydd yn gyson ar 100%. Mae'r gosodiad perfformiad yn sicrhau'r perfformiad prosesydd cyflymaf. Darllenwch, er enghraifft, am force_turbo paramedr yn Raspberry Piy bydd y panel RPi yn defnyddio'r rheolydd ag ef perfformiad, lle bydd y gwelliant perfformiad yn fwy amlwg oherwydd y cyflymder cloc CPU isel.

Defnyddio pm statig i gyflawni perfformiad gweinydd mwyaf posibl

Opsiwn PHP-FPM pm sefydlog yn dibynnu i raddau helaeth ar y cof am ddim ar y gweinydd. Os yw'r cof yn isel, mae'n well dewis ar alw neu deinamig. Ar y llaw arall, os oes gennych gof, gallwch osgoi gorbenion y rheolwr proses PHP trwy osod pm sefydlog i gapasiti mwyaf y gweinydd. Mewn geiriau eraill, os yw popeth wedi'i gyfrifo'n dda, mae angen i chi sefydlu pm.statig i'r cyfaint uchaf o brosesau PHP-FPM y gellir eu gweithredu, heb greu problemau gyda chof isel neu storfa. Ond nid mor uchel nes ei fod yn llethu'r proseswyr ac yn cronni criw o weithrediadau PHP-FPM yn aros i gael eu gweithredu.

Yn y screenshot uchod, mae gan y gweinydd pm = statig a pm.max_children = 100, ac mae hyn yn cymryd tua 10 GB allan o'r 32 sydd ar gael. Rhowch sylw i'r colofnau a amlygwyd, mae popeth yn glir yma. Yn y sgrinlun hwn roedd tua 200 o ddefnyddwyr gweithredol (mwy na 60 eiliad) yn Google Analytics. Ar y lefel hon, mae tua 70% o brosesau plant PHP-FPM yn dal i fod yn segur. Mae hyn yn golygu bod PHP-FPM bob amser wedi'i osod i'r uchafswm o adnoddau gweinydd waeth beth fo'r traffig presennol. Mae proses segur yn aros am uchafbwyntiau traffig ac yn ymateb yn syth. Does dim rhaid i chi aros tan pm yn creu prosesau plentyn ac yna'n eu terfynu pan ddaw'r cyfnod i ben pm.process_idle_timeout. Gosodais y gwerth i uchel iawn pm.max_requestsoherwydd mae hwn yn weinydd sy'n gweithio heb unrhyw ollyngiadau cof yn PHP. Gallwch chi osod pm.max_requests = 0 gyda statig os ydych yn gwbl hyderus mewn sgriptiau PHP presennol ac yn y dyfodol. Ond mae'n well ail-redeg y sgriptiau dros amser. Gosod nifer fawr o geisiadau, oherwydd rydym am osgoi costau pm diangen. Er enghraifft, o leiaf pm.max_requests = 1000 - yn dibynnu ar faint pm.max_plant a nifer y ceisiadau yr eiliad.

Mae'r sgrin yn dangos y gorchymyn Linux uchaf, wedi'i hidlo gan u (defnyddiwr) ac enw defnyddiwr PHP-FPM. Dim ond y 50 neu fwy o brosesau cyntaf sy'n cael eu dangos (doeddwn i ddim yn cyfrif yn union), ond yn ei hanfod mae'r brig yn dangos yr ystadegau gorau sy'n ffitio i ffenestr y derfynell. Yn yr achos hwn wedi'i drefnu yn ôl % CPU (% CPU). I weld yr holl brosesau 100 PHP-FPM, rhedeg y gorchymyn:

top -bn1 | grep php-fpm

Pryd i ddefnyddio pm ondemand a deinamig

Os ydych yn defnyddio pm deinamig, mae gwallau fel hyn yn digwydd:

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

Ceisiwch newid y paramedr, ni fydd y gwall yn diflannu, fel a ddisgrifir yn y post hwn ar Serverfault. Yn yr achos hwn, roedd y gwerth pm.min yn rhy fach, a chan fod traffig gwe yn amrywio cymaint a bod ganddo gopaon uchel a dyffrynnoedd dwfn, mae'n anodd addasu pm yn ddigonol deinamig. Fel arfer defnyddir pm ar alw, fel y cynghorwyd yn yr un swydd. Ond mae hyn yn waeth byth, oherwydd ar alw yn terfynu prosesau segur i sero pan nad oes fawr ddim traffig, os o gwbl, a byddwch yn dal i fod â gorbenion traffig sy'n newid. Oni bai, wrth gwrs, eich bod yn gosod amser aros enfawr. Ac yna mae'n well ei ddefnyddio pm.statig + nifer uchel pm.max_requests.

PM deinamig ac yn arbennig ar alw efallai y bydd yn ddefnyddiol os oes gennych chi sawl pwll PHP-FPM. Er enghraifft, rydych chi'n cynnal cyfrifon cPanel lluosog neu wefannau lluosog mewn gwahanol byllau. Mae gen i weinydd gyda, dyweder, 100+ o gyfrifon cpanel a thua 200 o barthau, ac ni fyddai pm.static neu hyd yn oed deinamig yn fy arbed. Y cyfan sydd ei angen arnoch chi yma ar alw, wedi'r cyfan, mae mwy na dwy ran o dair o wefannau yn derbyn fawr ddim traffig, os o gwbl, a chyda ar alw bydd holl brosesau plentyn yn cwympo i ffwrdd, a fydd yn arbed llawer o gof i ni! Yn ffodus, sylwodd datblygwyr cPanel ar hyn a gosododd y gwerth yn ddiofyn ar alw. Yn flaenorol, pan oedd y rhagosodiad deinamig, Nid oedd PHP-FPM yn addas ar gyfer gweinyddwyr prysur a rennir o gwbl. Mae llawer wedi defnyddio suPHP, oherwydd pm deinamig cof a ddefnyddir hyd yn oed gyda phyllau segur a chyfrifon cPanel PHP-FPM. Yn fwyaf tebygol, os yw'r traffig yn dda, ni fyddwch yn cael eich cynnal ar weinydd gyda nifer fawr o byllau PHP-FPM (hosting a rennir).

Casgliad

Os ydych chi'n defnyddio PHP-FPM a bod eich traffig yn drwm, rheolwyr proses ar alw и deinamig ar gyfer PHP-FPM bydd trwybwn cyfyngedig oherwydd eu gorbenion cynhenid. Deall eich system a ffurfweddu prosesau PHP-FPM yn unol â chynhwysedd mwyaf y gweinydd. Set gyntaf pm.max_plant yn dibynnu ar uchafswm defnydd pm deinamig neu ar alw, ac yna cynyddu'r gwerth hwn i lefel lle bydd y cof a'r prosesydd yn gweithio heb gael eu gorlwytho. Byddwch yn sylwi ar hynny gyda pm sefydlog, Gan fod gennych bopeth yn y cof, bydd pigau traffig yn achosi llai o bigau CPU dros amser, a bydd cyfartaleddau llwyth gweinydd a CPU yn gwastatáu. Mae maint proses PHP-FPM ar gyfartaledd yn dibynnu ar y gweinydd gwe ac mae angen cyfluniad llaw, felly mae rheolwyr prosesau mwy awtomataidd deinamig и ar alw - yn fwy poblogaidd. Rwy'n gobeithio bod yr erthygl yn ddefnyddiol.

DIWEDDARIAD Ychwanegwyd siart meincnod ab. Os yw prosesau PHP-FPM yn y cof, mae perfformiad yn cynyddu ar draul defnydd cof lle maent yn eistedd ac yn aros. Dewch o hyd i'r opsiwn gorau i chi'ch hun.

Ffynhonnell: hab.com