PHP-FPM စနစ်ထည့်သွင်းခြင်း- အမြင့်ဆုံးစွမ်းဆောင်ရည်အတွက် pm static ကိုသုံးပါ။

ဤဆောင်းပါး၏ တည်းဖြတ်မထားသော ဗားရှင်းကို မူလက ထုတ်ဝေခဲ့သည်။ haydenjames.io သူမ၏ ခွင့်ပြုချက်ဖြင့် ဤနေရာတွင် ထုတ်ဝေခဲ့သည်။ စာရေးသူ.

အတိုချုပ်အားဖြင့် သင့်အား PHP-FPM ကို ဖြတ်သန်းမှုကို တိုးမြှင့်ရန်၊ latency လျှော့ချရန်နှင့် CPU နှင့် memory ကို ပို၍ တသမတ်တည်း အသုံးပြုရန် PHP-FPM ကို မည်သို့ အကောင်းဆုံး configure လုပ်ရမည်ကို ပြောပြပါမည်။ ပုံမှန်အားဖြင့်၊ PHP-FPM ရှိ PM (လုပ်ငန်းစဉ်မန်နေဂျာ) လိုင်းသည် ဖြစ်သည်။ ပြောင်းလဲနေသောပြီးတော့ သင့်မှာ လုံလောက်တဲ့ Memory မရှိဘူးဆိုရင် Install လုပ်တာက ပိုကောင်းပါတယ်။ ဝယ်လိုအားအပေါ်. php.net စာရွက်စာတမ်းအပေါ်အခြေခံ၍ ထိန်းချုပ်မှုရွေးချယ်စရာ ၂ ခုကို နှိုင်းယှဉ်ပြီး ကျွန်ုပ်အနှစ်သက်ဆုံးသည် ၎င်းတို့နှင့် မည်သို့ကွာခြားသည်ကို ကြည့်ကြပါစို့ တည်ငြိမ်သော ထုထည်မြင့်မားသော ယာဉ်အသွားအလာအတွက် ညနေ

pm = သွက်လက်သည်။ — အောက်ဖော်ပြပါ ညွှန်ကြားချက်များအပေါ် အခြေခံ၍ ကလေးလုပ်ငန်းစဉ်များ၏ အရေအတွက်အား ဒိုင်းနမစ်ဖြင့် ဖွဲ့စည်းထားပါသည်။ pm.max_children၊ pm.start_servers၊pm.min_spare_servers၊ pm.max_spare_servers.
pm = လိုအပ်သည် - လုပ်ငန်းစဉ်များကို လိုအပ်ချက်အရ ဖန်တီးထားပါသည် (ဝန်ဆောင်မှုစတင်သည့်အခါ pm.start_servers ကို စတင်သောအခါတွင် ပြောင်းလဲနေသော ဖန်တီးမှုနှင့် ဆန့်ကျင်ဘက်ဖြစ်သည်)။
pm = အငြိမ် - ကလေးလုပ်ငန်းစဉ်အရေအတွက်ကို ပုံသေသတ်မှတ်ထားပြီး ကန့်သတ်ချက်ဖြင့် ညွှန်ပြထားသည်။ pm.max_ကလေးများ.

အသေးစိတ်ကို ကြည့်ပါ။ ကမ္ဘာလုံးဆိုင်ရာ လမ်းညွှန်ချက်များ php-fpm.conf စာရင်း အပြည့်အစုံ.

PHP-FPM လုပ်ငန်းစဉ်မန်နေဂျာနှင့် CPU ကြိမ်နှုန်းထိန်းချုပ်သူကြား တူညီမှုများ

၎င်းသည် ပြင်ပအကြောင်းအရာဟုထင်ရသော်လည်း ၎င်းကို PHP-FPM ဖွဲ့စည်းမှုဆိုင်ရာ အကြောင်းအရာနှင့် ချိတ်ဆက်သွားမည်ဖြစ်သည်။ လက်ပ်တော့၊ virtual machine သို့မဟုတ် သီးခြားဆာဗာတွင် ပရိုဆက်ဆာနှေးကွေးမှု အနည်းဆုံးတစ်ကြိမ် မကြုံဖူးသူမှာ မည်သူနည်း။ CPU ကြိမ်နှုန်း အတိုင်းအတာကို မှတ်မိပါသလား။ ဤရွေးချယ်စရာများအတွက် ရရှိနိုင်ပါသည်။ nix နှင့် Windows သည် ပရိုဆက်ဆာအခိုးအငေါ့ဆက်တင်ကို ပြောင်းလဲခြင်းဖြင့် စနစ်စွမ်းဆောင်ရည်နှင့် တုံ့ပြန်မှုကို မြှင့်တင်နိုင်သည်။ ဝယ်လိုအားအပေါ် အပေါ် စွမ်းဆောင်ရည်*။ ဒီတစ်ခါမှာတော့ ဖော်ပြချက်တွေကို နှိုင်းယှဉ်ပြီး တူညီမှုတွေကို ကြည့်ကြရအောင်။

Governor=ondemand - လက်ရှိဝန်ပေါ် မူတည်၍ ပရိုဆက်ဆာကြိမ်နှုန်း၏ ဒိုင်းနမစ်စကေးချဲ့ခြင်း။ အမြင့်ဆုံးကြိမ်နှုန်းသို့ လျင်မြန်စွာ ခုန်ဆင်းပြီးနောက် လှုပ်ရှားမှုမရှိသည့်ကာလများ တိုးလာသည်နှင့်အမျှ ၎င်းကို လျှော့ချသည်။
ဝန်=ရှေးရိုးစွဲ= လက်ရှိဝန်ပေါ်မူတည်၍ dynamic frequency scaling။ ondemand ထက် ကြိမ်နှုန်းကို ပိုမိုချောမွေ့စွာ တိုးပြီး လျှော့ချပါ။
အုပ်ချုပ်ရေးမှူး = စွမ်းဆောင်ရည် - ကြိမ်နှုန်းသည် အမြဲတမ်း အများဆုံးဖြစ်သည်။

အသေးစိတ်ကို ကြည့်ပါ။ ပရိုဆက်ဆာ ကြိမ်နှုန်းထိန်းချုပ်မှု ကန့်သတ်ချက်များစာရင်းအပြည့်အစုံ.

တူညီမှုများကိုကြည့်ပါ? အသုံးပြုရန် အကောင်းဆုံးဖြစ်ကြောင်း သင့်အား ယုံကြည်စေရန် ဤနှိုင်းယှဉ်မှုကို ပြသလိုပါသည်။ ညနေဈေးတန်း PHP-FPM အတွက်

ပရိုဆက်ဆာအတွက် ထိန်းညှိမှု ကန့်သတ်ချက် စွမ်းဆောင်ရည် ဆာဗာ၏ CPU ကန့်သတ်ချက်ပေါ်တွင် လုံးဝနီးပါးမူတည်သောကြောင့် စွမ်းဆောင်ရည်ကို လုံခြုံစွာ တိုးမြှင့်ရန် ကူညီပေးသည်။ ၎င်းအပြင်၊ အပူချိန်၊ ဘက်ထရီအား (လက်ပ်တော့တစ်လုံးတွင်) နှင့် ပရိုဆက်ဆာကို 100% အဆက်မပြတ်လည်ပတ်ခြင်း၏ အခြားဘေးထွက်ဆိုးကျိုးများကဲ့သို့သော အချက်များလည်း ရှိပါသည်။ စွမ်းဆောင်ရည် ဆက်တင်သည် အမြန်ဆုံး ပရိုဆက်ဆာ စွမ်းဆောင်ရည်ကို သေချာစေသည်။ ဥပမာ၊ အကြောင်းဖတ်ပါ။ Raspberry Pi ရှိ force_turbo ကန့်သတ်ချက်RPi panel သည် regulator ကို အသုံးပြုမည် ဖြစ်သည်။ စွမ်းဆောင်ရည်CPU clock speed နိမ့်ခြင်းကြောင့် စွမ်းဆောင်ရည် တိုးတက်မှု ပိုသိသာလာပါမည်။

ဆာဗာစွမ်းဆောင်ရည်အမြင့်ဆုံးရရှိရန် pm static ကိုအသုံးပြုခြင်း။

PHP-FPM ရွေးချယ်မှု ညနေဈေးတန်း ဆာဗာပေါ်ရှိ အခမဲ့မှတ်ဉာဏ်ပေါ်တွင် များစွာမူတည်ပါသည်။ Memory နည်းရင် ရွေးတာ ပိုကောင်းပါတယ်။ ဝယ်လိုအားအပေါ် သို့မဟုတ် ပြောင်းလဲနေသော. အခြားတစ်ဖက်တွင်၊ သင့်တွင် memory ရှိပါက pm ကိုသတ်မှတ်ခြင်းဖြင့် PHP process manager overhead ကိုရှောင်ရှားနိုင်သည်။ တည်ငြိမ်သော အမြင့်ဆုံးဆာဗာ စွမ်းရည်အထိ။ တစ်နည်းဆိုရသော် အရာရာတိုင်းကို ကောင်းမွန်စွာ တွက်ချက်ထားရန် လိုအပ်ပါသည်။ pm.static လုပ်ဆောင်နိုင်သော PHP-FPM လုပ်ငန်းစဉ်များ၏ အမြင့်ဆုံးပမာဏအထိ၊ မှတ်ဉာဏ်နည်းသော သို့မဟုတ် ကက်ရှ်ပြဿနာများ မဖန်တီးဘဲ။ သို့သော် ၎င်းသည် ပရိုဆက်ဆာများကို လွှမ်းမိုးပြီး လုပ်ဆောင်ရန်စောင့်ဆိုင်းနေသည့် PHP-FPM လုပ်ဆောင်ချက်များစွာကို စုဆောင်းထားသောကြောင့် မြင့်မားသည်မဟုတ်ပေ။.

အထက်ဖော်ပြပါ screenshot တွင်၊ ဆာဗာတွင်ရှိသည်။ pm = static နှင့် pm.max_children = 100၎င်းသည် ရရှိနိုင်သော 10 အနက်မှ 32 GB ခန့်အထိ နေရာယူသည်။ မီးမောင်းထိုးထားသည့် ကော်လံများကို အာရုံစိုက်ပါ၊ အရာအားလုံးသည် ဤနေရာတွင် ရှင်းပါသည်။ ဤဖန်သားပြင်ဓာတ်ပုံတွင် Google Analytics တွင် အသုံးပြုသူ ၂၀၀ ခန့် (စက္ကန့် 200 ကျော်) ရှိခဲ့သည်။ ဤအဆင့်တွင်၊ ခန့်မှန်းခြေအားဖြင့် PHP-FPM ကလေးလုပ်ငန်းစဉ်များ၏ 60% သည် အလုပ်မလုပ်သေးပါ။ ဆိုလိုသည်မှာ PHP-FPM သည် လက်ရှိအသွားအလာနှင့်မသက်ဆိုင်ဘဲ ဆာဗာရင်းမြစ်များ၏ အများဆုံးပမာဏသို့ အမြဲတမ်းသတ်မှတ်ထားသည်။ ရပ်နားထားသော လုပ်ငန်းစဉ်သည် ယာဉ်အသွားအလာ အထွတ်အထိပ်ကို စောင့်ပြီး ချက်ချင်းတုံ့ပြန်သည်။ သည်အထိစောင့်စရာမလိုပါ။ pm ကလေးလုပ်ငန်းစဉ်များကို ဖန်တီးပြီး သက်တမ်းကုန်ဆုံးသည့်အခါ ၎င်းတို့ကို ရပ်ဆိုင်းမည်ဖြစ်သည်။ pm.process_idle_timeout. တန်​ဖိုးအရမ်းမြင့်​တယ်​ pm.max_တောင်းဆိုချက်များအဘယ်ကြောင့်ဆိုသော်၎င်းသည် PHP တွင် memory ပေါက်ကြားခြင်းမရှိသောအလုပ်လုပ်သောဆာဗာဖြစ်သည်။ တပ်ဆင်နိုင်သည်။ pm.max_requests = 0 လက်ရှိနှင့် အနာဂတ် PHP script များကို သင် လုံးဝယုံကြည်ပါက static နှင့်။ ဒါပေမယ့် အချိန်ကြာလာတာနဲ့အမျှ ဇာတ်ညွှန်းတွေကို ပြန်ဖွင့်တာက ပိုကောင်းပါတယ်။ မလိုအပ်သော ညနေကုန်ကျစရိတ်များကို ရှောင်ရှားလိုသောကြောင့် တောင်းဆိုမှုအများအပြားကို သတ်မှတ်ပါ။ ဥပမာ အနည်းဆုံး pm.max_requests = 1000 - ပမာဏပေါ် မူတည် pm.max_ကလေးများ နှင့် တစ်စက္ကန့်လျှင် တောင်းဆိုမှုအရေအတွက်။

screenshot သည် command ကိုပြသသည်။ Linux ထိပ်တန်းu (အသုံးပြုသူ) နှင့် PHP-FPM အသုံးပြုသူအမည်ဖြင့် စစ်ထုတ်ထားသည်။ ပထမဆုံး လုပ်ငန်းစဉ် 50 သို့မဟုတ် ထို့ထက်ပိုသော လုပ်ငန်းစဉ်များကိုသာ ပြသသည် (အတိအကျတော့ မရေတွက်ခဲ့ပါ)၊ သို့သော် အဓိကအားဖြင့် ထိပ်တန်းသည် terminal window နှင့် ကိုက်ညီသော ထိပ်တန်းစာရင်းအင်းများကို ပြသည်။ ဤကိစ္စတွင် % CPU (%CPU) ဖြင့် စီထားသည်။ PHP-FPM လုပ်ငန်းစဉ် 100 လုံးကို ကြည့်ရန်၊ command ကို run ပါ။

top -bn1 | grep php-fpm

pm ondemand နဲ့ dynamic ကို ဘယ်အချိန်မှာ သုံးမလဲ။

ညနေသုံးရင် ပြောင်းလဲနေသောဤကဲ့သို့သော အမှားအယွင်းများ ဖြစ်ပေါ်လာသည်-

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

ပါရာမီတာကို ပြောင်းကြည့်ပါ၊ အမှားက ပျောက်သွားမှာ မဟုတ်ဘူး။ Serverfault တွင် ဤပို့စ်တွင် ဖော်ပြထားသည်။. ဤကိစ္စတွင်၊ pm.min တန်ဖိုးသည် သေးငယ်လွန်းသဖြင့် ဝဘ်လမ်းကြောင်းသည် အလွန်ကွဲပြားပြီး မြင့်မားသော တောင်ထွတ်များနှင့် နက်ရှိုင်းသောချိုင့်များရှိသောကြောင့် ညနေကို လုံလောက်စွာချိန်ညှိရန် ခက်ခဲပါသည်။ ပြောင်းလဲနေသော. အများအားဖြင့် ညနေကို သုံးတယ်။ ဝယ်လိုအားအပေါ်, တူညီသော ပို့စ်တွင် အကြံပြုထားသည့်အတိုင်း. ဒါပေမဲ့ ဒါက ပိုဆိုးတယ်ဆိုတော့ ဝယ်လိုအားအပေါ် အသွားအလာ အနည်းငယ် သို့မဟုတ် မရှိသည့်အခါတွင် ရပ်နားထားသော လုပ်ငန်းစဉ်များကို သုညအထိ ရပ်တန့်စေပြီး သင်သည် ပြောင်းလဲနေသော ယာဉ်ကြောအသွားအလာ၏ ထိပ်ပိုင်းနှင့် အဆုံးတိုင်မည်ဖြစ်သည်။ မဟုတ်လျှင် သင်သည် ကြီးမားသောစောင့်ဆိုင်းချိန်ကို သတ်မှတ်ပေးထားသည်။ ပြီးမှ သုံးရတာ ပိုကောင်းပါတယ်။ pm.static + နံပါတ်မြင့် pm.max_တောင်းဆိုချက်များ.

PM ပြောင်းလဲနေသော အထူးသဖြင့် ဝယ်လိုအားအပေါ် သင့်တွင် PHP-FPM ရေကူးကန်များစွာရှိလျှင် အဆင်ပြေနိုင်သည်။ ဥပမာအားဖြင့်၊ သင်သည် မတူညီသော အစုအဝေးများတွင် cPanel အကောင့်များစွာ သို့မဟုတ် ဝဘ်ဆိုဒ်များစွာကို လက်ခံဆောင်ရွက်ပေးသည်။ ကျွန်ုပ်တွင် 100+ cpanel အကောင့်များနှင့် ဒိုမိန်း 200 ခန့်ရှိသော ဆာဗာတစ်ခုရှိပြီး pm.static သို့မဟုတ် dynamic သည် ကျွန်ုပ်ကို ကယ်တင်မည်မဟုတ်ပါ။ သင်လိုအပ်သမျှသည်ဤတွင်ဖြစ်သည်။ ဝယ်လိုအားအပေါ်ပြီးနောက်၊ ဝဘ်ဆိုဒ်များ၏ သုံးပုံနှစ်ပုံကျော်သည် အသွားအလာ အနည်းငယ် သို့မဟုတ် လုံးဝမရှိဘဲ၊ ဝယ်လိုအားအပေါ် ကလေးလုပ်ငန်းစဉ်အားလုံး ပျက်သွားမည်ဖြစ်ပြီး၊ ၎င်းသည် ကျွန်ုပ်တို့အား မှတ်ဉာဏ်များစွာ သက်သာစေမည်ဖြစ်သည်။ ကံကောင်းထောက်မစွာ၊ cPanel developer များသည် ၎င်းကို သတိပြုမိပြီး တန်ဖိုးကို ပုံသေသတ်မှတ်ထားသည်။ ဝယ်လိုအားအပေါ်. အရင်က ပုံသေဖြစ်ခဲ့တယ်။ ပြောင်းလဲနေသောPHP-FPM သည် အလုပ်များသော မျှဝေထားသော ဆာဗာများအတွက် လုံးဝ မသင့်လျော်ပါ။ တော်တော်များများ သုံးဖူးတယ်။ suPHPညနေဆိုတော့ ပြောင်းလဲနေသော idle pool များနှင့် cPanel PHP-FPM အကောင့်များဖြင့်ပင် မမ်မိုရီကို သုံးစွဲထားသည်။ အသွားအလာကောင်းပါက၊ PHP-FPM pools အများအပြား (shared hosting) ဖြင့် သင့်အား ဆာဗာတွင် လက်ခံကျင်းပမည်မဟုတ်ပါ။

ကောက်ချက်

အကယ်၍ သင်သည် PHP-FPM ကိုအသုံးပြုနေပြီး သင်၏အသွားအလာ များပြားပါက၊ လုပ်ငန်းစဉ်မန်နေဂျာများ ဝယ်လိုအားအပေါ် и ပြောင်းလဲနေသော PHP-FPM သည် ၎င်းတို့၏ မွေးရာပါ အကျုံးဝင်မှုကြောင့် ကန့်သတ်ချက်ရှိမည်ဖြစ်သည်။ သင်၏စနစ်အား နားလည်ပြီး အမြင့်ဆုံးဆာဗာစွမ်းရည်အလိုက် PHP-FPM လုပ်ငန်းစဉ်များကို စီစဉ်သတ်မှတ်ပါ။ ပထမအစုံ pm.max_ကလေးများ အများဆုံးညနေအသုံးပြုမှုပေါ် မူတည် ပြောင်းလဲနေသော သို့မဟုတ် ဝယ်လိုအားအပေါ်ပြီးလျှင် ဤတန်ဖိုးကို မမ်မိုရီနှင့် ပရိုဆက်ဆာသည် ဝန်ပိုမချဘဲ အလုပ်လုပ်မည့်အဆင့်သို့ တိုးပါ။ အဲဒါကို သင်သတိထားမိပါလိမ့်မယ်။ ညနေဈေးတန်းသင့်တွင် အရာအားလုံးကို မန်မိုရီတွင်ရှိသောကြောင့်၊ အသွားအလာ spikes များသည် အချိန်ကြာလာသည်နှင့်အမျှ CPU spikes နည်းပါးလာမည်ဖြစ်ပြီး server နှင့် CPU load များ ပျမ်းမျှထွက်ရှိလာမည်ဖြစ်သည်။ ပျမ်းမျှ PHP-FPM လုပ်ငန်းစဉ်အရွယ်အစားသည် ဝဘ်ဆာဗာပေါ်တွင်မူတည်ပြီး manual configuration လိုအပ်သောကြောင့် ပိုမိုအလိုအလျောက်လုပ်ဆောင်သည့် မန်နေဂျာများသည်၊ ပြောင်းလဲနေသော и ဝယ်လိုအားအပေါ် - ပိုနာမည်ကြီးတယ်။ ဆောင်းပါးက အသုံးဝင်မယ်လို့ မျှော်လင့်ပါတယ်။

DUP စံပြဇယားကို ထည့်သွင်းထားသည်။ ab. PHP-FPM လုပ်ငန်းစဉ်များသည် မမ်မိုရီတွင်ရှိနေပါက၊ ၎င်းတို့ ထိုင်စောင့်နေသည့် မန်မိုရီသုံးစွဲမှုစရိတ်ဖြင့် စွမ်းဆောင်ရည် တိုးလာပါသည်။ သင့်အတွက် အကောင်းဆုံးရွေးချယ်မှုကို ရှာဖွေပါ။

source: www.habr.com