Cyfeiriadur Erthygl
Mae nifer y defnyddwyr cydamserol y gall gweinydd eu trin yn dibynnu nid ar faint o greiddiau sydd ganddo, ond ar faint o gof y mae pob proses yn ei ddefnyddio.
Efallai bod y datganiad hwn yn swnio fel pryfociad, ond dyma'r profiad mwyaf real a phoenus yn y diwydiant gweithrediadau a chynnal a chadw.
Pam mai cof yw'r prif dagfa?
Mae llawer o bobl yn gweld VPS gyda CPU 8-craidd a 24GB o gof ac yn meddwl yn isymwybodol y gallant redeg cannoedd o brosesau PHP-FPM yn hawdd.
Fodd bynnag, mewn gwirionedd, mae defnydd cof RSS un broses PHP yn aml mor uchel â 200MB.
Dyma'r canlyniad a gafwyd trwy brofion gwirioneddol trwy'r llinell orchymyn:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
Yn fframwaith cymhleth ac amgylchedd aml-ategyn HestiaCP , yn enwedig heb optimeiddio OPcache, 200MB yw'r norm.
Mae hwyrach bod y cof, nid y CPU, yn derfyn caled sy'n pennu'r cyfochredd mwyaf.
Ffeil ffurfweddu a argymhellir (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
Rhesymeg cyfrifo paramedr a sail gosod
| Paramedrau ffurfweddu | Gosod gwerth | Cyfrifiad craidd a sail sefydlu |
|---|---|---|
| pm | dynamic | Mae modd deinamig yn caniatáu ychwanegu neu ddileu prosesau'n elastig yn seiliedig ar ofynion cydamseredd, gan gydbwyso cyflymder ymateb a defnydd cof. |
| pm.max_plant | 80 | 24GB o gof cyfanswm heb graidd y system a MySQL/RedisAr ôl Nginx, mae tua 16GB ar ôl ar gyfer PHP.16,384 MB / 200 MB ≈ 81.9Gall ei osod i 80 ddileu OOM (Allan o Gof) yn llwyr yn ystod cydamseredd uchel. |
| pm.start_servers | 16 | Mae cynhesu ymlaen llaw wrth gychwyn wedi'i osod i ddwywaith nifer y creiddiau CPU (8 craidd × 2 = 16) i sicrhau y gall y gwasanaeth ymdrin â chydamseredd sylfaenol ar unwaith ar ôl ailgychwyn. |
| gweinyddion_sbâr_pm.min | 8 | Gosodwch gyfrif craidd y CPU i 8 craidd i sicrhau y gellir ymateb i geisiadau newydd ar unrhyw adeg yn ystod cyfnodau traffig isel. |
| gweinyddion_sbâr_pm.max | 24 | Gosodwch ef i 3 gwaith nifer y creiddiau CPU (8 craidd × 3 = 24) i gadw nifer cymedrol o brosesau ar ôl i'r traffig leihau, er mwyn ymdopi ag amrywiadau ysgafn. |
| pm.max_requests | 500 | Os yw un broses yn cyrraedd sylfaen fawr o 200MB, gall lleihau nifer y ceisiadau i 500 cyn dinistrio ac ailadeiladu lanhau gollyngiadau cof ymhlyg yn gyflymach. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Caiff prosesau segur eu rhyddhau'n awtomatig a'u dychwelyd i gof y system ar ôl 10 eiliad heb unrhyw geisiadau. |
Gosodiadau Cefnogol Hanfodol ac Awgrymiadau Optimeiddio
1. Mecanwaith gwrth-ben mawr amserol
request_terminate_timeout = 60s Dyna'r allwedd.
Gall derfynu prosesau sydd wedi'u sownd oherwydd sefyllfa lle nad yw'r gronfa ddata wedi'i chloi neu rwystro API trydydd parti yn orfodol.
Yn y cyfamser, Nginx fastcgi_read_timeout Rhaid ei gadw am o leiaf 60 eiliad, fel arall bydd y cleient yn ei dderbyn yn gynamserol. 504 Gateway Timeout.
2. Strategaethau i oresgyn tagfeydd cof
Mae uchafswm o 80 o brosesau cydamserol yn golygu, o dan amodau cydamseredd eithafol, y gall y system drin uchafswm o 80 o geisiadau HTTP deinamig ar yr un pryd.
Os ydych chi am wella capasiti ymhellach, dylai'r ffocws fod ar leihau'r defnydd o gof fesul proses.
- Galluogi OPcache： 在
php.iniFfurfweddiad canoligopcache.enable=1及opcache.memory_consumption=256Gall storio cod byte leihau'r defnydd o gof ar gyfer un broses o 200MB i 60~100MB. - Rheolaeth resymol o gyfyngiad_memory：将
php.inicanolmemory_limitCyfyngedig i128M或256MEr mwyn atal sgriptiau annormal unigoldiderfynMae'n defnyddio llawer o gof.
Unwaith y bydd defnydd cof un broses yn gostwng i 100MB...pm.max_children Gellir ei uwchraddio'n ddiogel i 150 Yn ogystal, mae'r gallu cydamserol bron wedi dyblu.
Safbwyntiau awdurdodol a ddyfynnwyd
Yn ôl yr argymhellion yn nogfennaeth swyddogol Nginx :
"Dylid monitro cymwysiadau FastCGI bob amser gyda chyfarwyddebau terfyn amser i atal gorlifo adnoddau."
(Ffynhonnell: Dogfennau Nginx)
Mae llawlyfr swyddogol PHP yn datgan yn glir:
"Mae pm.max_children yn diffinio'r nifer uchaf o brosesau plant i'w creu. Dyma'r gyfarwyddeb bwysicaf."
(Ffynhonnell: Dogfennaeth PHP-FPM)
Mae'r safbwyntiau awdurdodol hyn yn cyd-fynd yn berffaith â'n harferion, gan brofi nad yw rhesymeg optimeiddio yn seiliedig ar brofiad yn unig, ond hefyd ar arferion gorau safonol.
Casgliad: Fy Safbwyntiau a Dyfyniadau Allweddol
Mewn senarios cydamserol uchel, y CPU yw'r injan, y cof yw'r tanc tanwydd, a PHP-FPM yw'r dosbarthwr fflyd.
Ni waeth pa mor bwerus yw'r injan, os nad yw'r tanc tanwydd yn ddigon mawr, ni fydd y confoi yn mynd yn bell iawn.
Nid yw arbenigwyr go iawn yn cynyddu'r paramedrau'n ddall, ond yn hytrach yn cyfrifo'n fanwl gywir faint o gof mae pob proses yn ei ddefnyddio er mwyn osgoi gwastraff a gorlif.
Hanfod optimeiddio yw dod o hyd i'r cydbwysedd gorau posibl gydag adnoddau cyfyngedig.
Nid technoleg yn unig yw hon, ond athroniaeth hefyd.
Felly, stopiwch gredu bod "nifer y creiddiau yn pennu popeth." Yr hyn sy'n pennu'r terfyn cydamseredd mewn gwirionedd yw eich rheolaeth dros y cof.
Cymerwch gamau ac optimeiddiwch eich VPS i'w botensial llawn, gan wneud y gorau o bob diferyn o gof.
Gobeithio y bydd yr erthygl "8-core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP" a rennir ar flog Chen Weiliang ( https://www.chenweiliang.com/ ) o gymorth i chi.
Mae croeso i chi rannu'r ddolen erthygl hon: https://www.chenweiliang.com/cwl-34509.html