ဆောင်းပါးလမ်းညွှန်
ဆာဗာတစ်ခု ကိုင်တွယ်နိုင်သော တပြိုင်နက်တည်းအသုံးပြုသူအရေအတွက်သည် ၎င်းတွင် core မည်မျှရှိသည်ပေါ်တွင် မူတည်ခြင်းမဟုတ်ဘဲ လုပ်ငန်းစဉ်တစ်ခုစီသည် မှတ်ဉာဏ်မည်မျှအသုံးပြုသည်ပေါ်တွင် မူတည်သည်။
ဤဖော်ပြချက်သည် ရန်စမှုတစ်ခုကဲ့သို့ ထင်ရသော်လည်း လုပ်ငန်းလည်ပတ်မှုနှင့် ပြုပြင်ထိန်းသိမ်းမှုလုပ်ငန်းတွင် အမှန်ကန်ဆုံးနှင့် အနာကျင်ဆုံးအတွေ့အကြုံဖြစ်သည်။
မှတ်ဉာဏ်ဟာ ဘာကြောင့် အဓိက အဟန့်အတား ဖြစ်နေတာလဲ။
လူအတော်များများက 8-core CPU နဲ့ 24GB memory ပါတဲ့ VPS တစ်ခုကို မြင်ပြီး PHP-FPM process ရာပေါင်းများစွာကို အလွယ်တကူ run နိုင်တယ်လို့ မသိစိတ်က ထင်ကြပါတယ်။
သို့သော်၊ အမှန်တကယ်တွင်၊ PHP process တစ်ခုတည်း၏ RSS memory အသုံးပြုမှုသည် မကြာခဏ 200MB အထိ မြင့်မားလေ့ရှိသည် ။
command line မှတစ်ဆင့် လက်တွေ့စမ်းသပ်မှုမှတစ်ဆင့် ရရှိသော ရလဒ်မှာ အောက်ပါအတိုင်းဖြစ်သည်။
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP ရဲ့ ရှုပ်ထွေးတဲ့ framework နဲ့ multi-plugin environment မှာ ၊ အထူးသဖြင့် OPcache optimization မပါဝင်ရင်၊ 200MB က ပုံမှန်ပါပဲ။
ဆိုလိုသည်မှာ အမြင့်ဆုံး တစ်ပြိုင်နက်တည်းအသုံးပြုမှုကို ဆုံးဖြတ်ပေးသည့် hard limit မှာ CPU မဟုတ်ဘဲ memory ဖြစ်သည်။
အကြံပြုထားသော configuration ဖိုင် (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
ကန့်သတ်ချက်တွက်ချက်မှုယုတ္တိဗေဒနှင့် ဆက်တင်အခြေခံ
| သတ်မှတ်ချက်ဘောင်များ | တန်ဖိုးသတ်မှတ်ခြင်း | Core တွက်ချက်မှုနှင့် setup အခြေခံ |
|---|---|---|
| pm | dynamic | Dynamic mode သည် response speed နှင့် memory utilization ကို ဟန်ချက်ညီအောင်ထိန်းညှိပေးခြင်း၊ တစ်ပြိုင်နက်တည်းလိုအပ်ချက်များအပေါ် အခြေခံ၍ process များကို elastic add-on သို့မဟုတ် delete လုပ်ခွင့်ပြုသည်။ |
| pm.max_ကလေးများ | 80 | system kernel မပါသော စုစုပေါင်း မှတ်ဉာဏ် 24GB နှင့် က MySQL/RedisNginx ပြီးရင် PHP အတွက် 16GB လောက် ကျန်ပါတယ်။16,384 MB / 200 MB ≈ 81.9၎င်းကို 80 သို့သတ်မှတ်ခြင်းဖြင့် တစ်ပြိုင်နက်တည်းမြင့်မားနေချိန်တွင် OOM (မှတ်ဉာဏ်မထွက်ခြင်း) ကို လုံးဝဖယ်ရှားနိုင်သည်။ |
| pm.start_servers | 16 | ပြန်လည်စတင်ပြီးနောက် ဝန်ဆောင်မှုသည် အခြေခံတစ်ပြိုင်နက်တည်းလုပ်ဆောင်မှုများကို ချက်ချင်းကိုင်တွယ်နိုင်စေရန်အတွက် စတင်ချိန်တွင် ကြိုတင်အပူပေးခြင်းကို CPU cores အရေအတွက်၏ နှစ်ဆ (8 cores × 2 = 16) ဟု သတ်မှတ်ထားသည်။ |
| pm.min_spare_servers | 8 | သွားလာမှုနည်းသောကာလများတွင် တောင်းဆိုမှုအသစ်များကို အချိန်မရွေး တုံ့ပြန်နိုင်စေရန်အတွက် CPU core အရေအတွက်ကို 8 cores သတ်မှတ်ပါ။ |
| pm.max_spare_servers | 24 | နှေးကွေးသော အတက်အကျများကို ကိုင်တွယ်နိုင်ရန်အတွက် ယာဉ်ကြောပိတ်ဆို့မှု လျော့ကျသွားပြီးနောက် လုပ်ငန်းစဉ်အသင့်အတင့်ကို ထိန်းသိမ်းထားရန်အတွက် CPU cores အရေအတွက်၏ ၃ ဆ (8 cores × 3 = 24) သို့ သတ်မှတ်ပါ။ |
| pm.max_တောင်းဆိုချက်များ | 500 | လုပ်ငန်းစဉ်တစ်ခုတည်းသည် 200MB ကြီးမားသော အခြေခံသို့ရောက်ရှိပါက တောင်းဆိုမှုအရေအတွက် ၅၀၀ အထိ လျှော့ချခြင်းဖြင့် လုပ်ငန်းစဉ်ကို ဖျက်ဆီးပြီး ပြန်လည်တည်ဆောက်မည်ဖြစ်ပြီး မှတ်ဉာဏ်ယိုစိမ့်မှုများကို ပိုမိုမြန်ဆန်စွာ ရှင်းလင်းပေးနိုင်ပါသည်။ |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers တောင်းဆိုမှုမရှိဘဲ ၁၀ စက္ကန့်အကြာတွင် အားလပ်နေသော လုပ်ငန်းစဉ်များကို အလိုအလျောက် ထုတ်လွှတ်ပြီး စနစ်မှတ်ဉာဏ်သို့ ပြန်ပို့ပါသည်။ |
မရှိမဖြစ် ပံ့ပိုးမှုဆက်တင်များနှင့် အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ခြင်းဆိုင်ရာ အကြံပြုချက်များ
၁။ Timeout anti-hangover ယန္တရား
request_terminate_timeout = 60s အဲဒါက အဓိကပဲ။
၎င်းသည် database ပိတ်ဆို့မှု သို့မဟုတ် third-party API ပိတ်ဆို့ခြင်းကြောင့် တုံ့ဆိုင်းနေသော လုပ်ငန်းစဉ်များကို အတင်းအကြပ် ရပ်ဆိုင်းနိုင်သည်။
တစ်ချိန်တည်းမှာပဲ၊ Nginx ရဲ့ fastcgi_read_timeout အနည်းဆုံး စက္ကန့် ၆၀ ထားရမည်၊ မဟုတ်ပါက client သည် အချိန်မတန်မီ ရရှိလိမ့်မည်။ 504 Gateway Timeout။
၂။ မှတ်ဉာဏ်အခက်အခဲများကို ကျော်လွှားရန် ဗျူဟာများ
အများဆုံး တစ်ပြိုင်နက်တည်း လုပ်ငန်းစဉ် ၈၀ ဆိုသည်မှာ အလွန်အမင်း တစ်ပြိုင်နက်တည်း အခြေအနေများတွင် စနစ်သည် တစ်ပြိုင်နက်တည်း dynamic HTTP request အများဆုံး ၈၀ ကို ကိုင်တွယ်နိုင်သည်ဟု ဆိုလိုသည်။
စွမ်းရည်ကို ပိုမိုတိုးတက်စေလိုပါက လုပ်ငန်းစဉ်တစ်ခုစီအတွက် မှတ်ဉာဏ်အသုံးပြုမှုကို လျှော့ချရန် အဓိကထားသင့်သည်။
- OPcache ကိုဖွင့်ပါ။: 在
php.iniအလတ်စားဖွဲ့စည်းပုံopcache.enable=1နှင့်opcache.memory_consumption=256Bytecode caching သည် single process တစ်ခု၏ memory usage ကို 200MB မှ 60~100MB အထိ လျှော့ချပေးနိုင်သည်။ - မှတ်ဉာဏ်ကန့်သတ်ချက်ကို ကျိုးကြောင်းဆီလျော်စွာ ထိန်းချုပ်ခြင်း：将
php.iniအလယ်တန်းmemory_limitကန့်သတ်ထားသည်128M或256Mတစ်ဦးချင်း ပုံမှန်မဟုတ်သော script များကို ကာကွယ်ရန်အကန့်အသတ်မရှိ၎င်းသည် မှတ်ဉာဏ်များစွာကို စားသုံးသည်။
လုပ်ငန်းစဉ်တစ်ခုတည်းရဲ့ မှတ်ဉာဏ်အသုံးပြုမှု 100MB အထိ ကျဆင်းသွားတာနဲ့...pm.max_children ၎င်းကို ဘေးကင်းစွာ အဆင့်မြှင့်တင်နိုင်သည် 150 ထို့အပြင် တစ်ပြိုင်နက်တည်း လုပ်ဆောင်နိုင်စွမ်းသည် နှစ်ဆနီးပါး မြင့်တက်လာခဲ့သည်။
ကိုးကားထားသော တရားဝင်အမြင်များ
တရားဝင် Nginx စာရွက်စာတမ်း ရှိ အကြံပြုချက်များ အရ -
"အရင်းအမြစ်များ ကုန်ခန်းသွားခြင်းမှ ကာကွယ်ရန်အတွက် FastCGI အပလီကေးရှင်းများကို timeout ညွှန်ကြားချက်များဖြင့် အမြဲစောင့်ကြည့်သင့်သည်။"
(ရင်းမြစ်- Nginx စာရွက်စာတမ်းများ)
PHP manual မှာ ရှင်းရှင်းလင်းလင်း ဖော်ပြထားပါတယ်။
"pm.max_children သည် ဖန်တီးရမည့် ကလေးလုပ်ငန်းစဉ်များ၏ အများဆုံးအရေအတွက်ကို သတ်မှတ်ပေးသည်။ ဤသည်မှာ အရေးကြီးဆုံး ညွှန်ကြားချက်ဖြစ်သည်။"
(ရင်းမြစ်- PHP-FPM စာရွက်စာတမ်း)
ဤအာဏာရအမြင်များသည် ကျွန်ုပ်တို့၏ အလေ့အကျင့်များနှင့် လုံးဝကိုက်ညီပြီး အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ခြင်းဆိုင်ရာယုတ္တိဗေဒသည် အတွေ့အကြုံပေါ်တွင်သာမက စံသတ်မှတ်ထားသော အကောင်းဆုံးအလေ့အကျင့်များအပေါ်တွင်လည်း အခြေခံထားကြောင်း သက်သေပြနေပါသည်။
နိဂုံးချုပ်- ကျွန်ုပ်၏အမြင်များနှင့် အဓိကကိုးကားချက်များ
တစ်ပြိုင်နက်တည်းလုပ်ဆောင်ရသည့် မြင့်မားသော အခြေအနေများတွင် CPU သည် အင်ဂျင်ဖြစ်ပြီး၊ မှတ်ဉာဏ်သည် လောင်စာဆီတိုင်ကီဖြစ်ပြီး၊ PHP-FPM သည် fleet dispatcher ဖြစ်သည်။
အင်ဂျင်က ဘယ်လောက်ပဲ ပါဝါကြီးပါစေ၊ လောင်စာဆီတိုင်ကီက လုံလောက်အောင် မကြီးမားဘူးဆိုရင် ယာဉ်တန်းက အဝေးကြီး မသွားနိုင်ပါဘူး။
စစ်မှန်သောကျွမ်းကျင်သူများသည် ကန့်သတ်ချက်များကို မျက်စိစုံမှိတ်၍ အမြင့်ဆုံးမသတ်မှတ်ကြဘဲ၊ အလဟဿဖြစ်မှုနှင့် အလွန်အကျွံဖြစ်မှု နှစ်မျိုးလုံးကို ရှောင်ရှားရန် လုပ်ငန်းစဉ်တစ်ခုစီ၏ မှတ်ဉာဏ်အသုံးပြုမှုကို တိကျစွာတွက်ချက်ကြသည်။
အကောင်းဆုံးဖြစ်အောင်လုပ်ဆောင်ခြင်းရဲ့ အနှစ်သာရကတော့ အကန့်အသတ်ရှိတဲ့ အရင်းအမြစ်တွေနဲ့ အကောင်းဆုံးဟန်ချက်ညီမှုကို ရှာဖွေဖို့ပါပဲ။
ဒါဟာ နည်းပညာတစ်ခုသာမကဘဲ၊ အတွေးအခေါ် တစ်ခုလည်း ဖြစ်ပါတယ် ။
ထို့ကြောင့် "core အရေအတွက်က အရာအားလုံးကို ဆုံးဖြတ်ပေးတယ်" ဟူသော ယုံကြည်ချက်ကို ရပ်လိုက်ပါ။ တစ်ပြိုင်နက်တည်း ကန့်သတ်ချက်ကို အမှန်တကယ် ဆုံးဖြတ်ပေးသည်မှာ မှတ်ဉာဏ်အပေါ် သင်၏ ထိန်းချုပ်မှုပင်ဖြစ်သည်။
မှတ်ဉာဏ်တစ်စက်ချင်းစီကို အကောင်းဆုံးအသုံးချပြီး သင့်ရဲ့ VPS ကို အပြည့်အဝ အလားအလာရှိအောင် လုပ်ဆောင်ပြီး အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ပါ။
Chen Weiliang ရဲ့ဘလော့ဂ် ( https://www.chenweiliang.com/ ) မှာ မျှဝေထားတဲ့ "8-core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP" ဆောင်းပါးက သင့်အတွက် အထောက်အကူဖြစ်လိမ့်မယ်လို့ မျှော်လင့်ပါတယ်။
ဒီဆောင်းပါးလင့်ခ်ကို မျှဝေပေးဖို့ မတွန့်ဆုတ်ပါနဲ့- https://www.chenweiliang.com/cwl-34509.html