Ilya Kosmodemyansky မှ "PostgreSQL စွမ်းဆောင်ရည်ကို တိုးတက်စေရန် Linux ချိန်ညှိခြင်း" မှ 2015 အစီရင်ခံစာ၏ စာသားမှတ်တမ်း
မသက်ဆိုင်ကြောင်းရှင်းလင်းချက်- ဤအစီရင်ခံစာသည် နိုဝင်ဘာလ 2015 ရက်စွဲပါရှိကြောင်း မှတ်သားထားပါသည် - 4 နှစ်ကျော်ကြာပြီး အချိန်များစွာ ကုန်ဆုံးသွားပါသည်။ အစီရင်ခံစာတွင် ဆွေးနွေးထားသော ဗားရှင်း 9.4 ကို ပံ့ပိုးမပေးတော့ပါ။ လွန်ခဲ့သော 4 နှစ်အတွင်း PostgreSQL ၏အသစ်ထွက်ရှိမှု 5 ခုကိုထုတ်ပြန်ခဲ့ပြီး Linux kernel ဗားရှင်း 15 ခုထွက်ရှိခဲ့သည်။ ဤစာပိုဒ်တိုများကို ပြန်လည်ရေးသားပါက၊ သင်သည် အခြားအစီရင်ခံစာတစ်ခုနှင့် အဆုံးသတ်မည်ဖြစ်သည်။ သို့သော် ဤနေရာတွင် ကျွန်ုပ်တို့သည် ယနေ့ထိသက်ဆိုင်ဆဲဖြစ်သည့် PostgreSQL အတွက် အခြေခံ Linux ချိန်ညှိခြင်းကို စဉ်းစားပါသည်။
ကျွန်တော့်နာမည် Ilya Kosmodemyansky ပါ။ ကျွန်တော် PostgreSQL-Consulting မှာ အလုပ်လုပ်ပါတယ်။ ယခု ကျွန်ုပ်သည် ယေဘုယျအားဖြင့် ဒေတာဘေ့စ်များနှင့် အထူးသဖြင့် PostgreSQL နှင့် စပ်လျဉ်း၍ Linux နှင့် မည်သို့လုပ်ဆောင်ရမည်အကြောင်း အနည်းငယ်ပြောပါမည်။
ငါတို့ ဘာအကြောင်းပြောကြမလဲ။ အကယ်၍ သင်သည် PostgreSQL နှင့် ဆက်သွယ်ပါက၊ အတိုင်းအတာတစ်ခုအထိ သင်သည် UNIX စီမံခန့်ခွဲသူဖြစ်ရန် လိုအပ်သည်။ ဘာကိုဆိုလိုတာလဲ? Oracle နှင့် PostgreSQL ကို နှိုင်းယှဉ်ပါက Oracle တွင် သင်သည် 80% DBA database admin နှင့် 20% Linux admin ဖြစ်ရန် လိုအပ်သည်။
PostgreSQL ဖြင့်၎င်းသည်အနည်းငယ်ပိုရှုပ်ထွေးသည်။ PostgreSQL ဖြင့် သင်သည် Linux အလုပ်လုပ်ပုံကို ပိုမိုနားလည်သဘောပေါက်ရန် လိုအပ်သည်။ တစ်ချိန်တည်းမှာပင်၊ မကြာသေးမီက အရာအားလုံးသည် ကောင်းမွန်စွာ မွမ်းမံပြင်ဆင်ထားသောကြောင့် စက်ခေါင်းနောက်ကို အနည်းငယ် ပြေးပါ။ နှင့် kernel အသစ်များ ထွက်လာပြီး လုပ်ဆောင်ချက်အသစ်များ ပေါ်လာသည်၊ စွမ်းဆောင်ရည် ပိုမိုကောင်းမွန်လာသည်၊ စသည်တို့ဖြစ်သည်။
ဘာကြောင့် Linux အကြောင်း ပြောနေတာလဲ။ ကျွန်ုပ်တို့သည် Linux ကွန်ဖရင့်တွင်ရှိနေသောကြောင့်မဟုတ်ပေ၊ သို့သော် ခေတ်သစ်အခြေအနေများတွင် ယေဘုယျအားဖြင့် databases ကိုအသုံးပြုရန်အတွက် အသင့်လျော်ဆုံးလည်ပတ်မှုစနစ်များထဲမှတစ်ခုဖြစ်ပြီး အထူးသဖြင့် PostgreSQL သည် Linux ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် FreeBSD သည် အလွန်ထူးဆန်းသော ဦးတည်ရာတစ်ခုတွင် ဖြစ်ထွန်းနေသောကြောင့်ဖြစ်သည်။ စွမ်းဆောင်ရည်နှင့် အခြားအရာများစွာနှင့် ပြဿနာများ ရှိလိမ့်မည်။ Windows ပေါ်ရှိ PostgreSQL ၏စွမ်းဆောင်ရည်သည် ယေဘုယျအားဖြင့် သီးခြားလေးနက်သောပြဿနာတစ်ခုဖြစ်ပြီး Windows တွင် UNIX နှင့်တူညီသောမျှဝေထားသောမှတ်ဉာဏ်မရှိပါက PostgreSQL သည် ၎င်းနှင့်ချိတ်ဆက်ထားသောကြောင့်၊ ၎င်းသည် multi-process စနစ်ဖြစ်သောကြောင့်ဖြစ်သည်။
Solaris လို exotics တွေကို လူတိုင်းက စိတ်မဝင်စားကြဘူးလို့ ကျွန်တော်ထင်ပါတယ်။
ခေတ်မီ Linux ဖြန့်ဖြူးမှုတွင် သင် kernel ကိုတည်ဆောက်ပုံပေါ်မူတည်၍ syctl ရွေးချယ်စရာ 1 ကျော်ရှိသည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် မတူညီသော အခွံမာသီးများကို ကြည့်လျှင် တစ်စုံတစ်ခုကို နည်းလမ်းများစွာဖြင့် ချိန်ညှိနိုင်သည်။ ၎င်းတို့ကို တပ်ဆင်နည်းတွင် ဖိုင်စနစ် ကန့်သတ်ချက်များ ရှိသည်။ ၎င်းကိုမည်သို့စတင်ရမည်နှင့်ပတ်သက်၍ သင့်တွင်မေးခွန်းများရှိပါက- BIOS တွင်မည်သို့ဖွင့်ရမည်၊ ဟာ့ဒ်ဝဲကိုမည်ကဲ့သို့ configure လုပ်ရမည်နည်း။
၎င်းသည် ရက်အတော်ကြာ ဆွေးနွေးနိုင်သည့် အလွန်ကြီးမားသော ပမာဏဖြစ်ပြီး အတိုချုံးထားသော အစီရင်ခံစာတစ်ခုတွင် မဟုတ်ဘဲ၊ ယခု ကျွန်ုပ်သည် အရေးကြီးသောအရာများ၊ သင့်ဒေတာဘေ့စ်ကို Linux တွင် ကောင်းမွန်စွာအသုံးပြုခြင်းမှ ကာကွယ်ရန် အာမခံထားသော အဆိုပါ rack များကို မည်သို့ရှောင်ရှားရမည်ကို ယခု ကျွန်ုပ်အာရုံစိုက်ပါမည်။ သူတို့ကို မပြင်ပါနှင့်။ တစ်ချိန်တည်းမှာပင်၊ အရေးကြီးသောအချက်မှာ ဒေတာဘေ့စ်အတွက် မှန်ကန်သော ဆက်တင်များတွင် ပုံသေဘောင်များစွာ မပါဝင်ခြင်းပင်ဖြစ်သည်။ ဆိုလိုသည်မှာ ပုံမှန်အားဖြင့် ၎င်းသည် ညံ့ဖျင်းသည် သို့မဟုတ် လုံးဝမလုပ်ဆောင်နိုင်ပါ။
Linux တွင် မည်သည့်အစဉ်အလာ ချိန်ညှိခြင်းပစ်မှတ်များ ရှိပါသလဲ။ သင် Linux စီမံခန့်ခွဲမှုကို ကိုင်တွယ်ဖြေရှင်းနေသောကြောင့် မည်သည့်အရာသည် ပစ်မှတ်ဖြစ်ကြောင်း ရှင်းပြရန် အထူးမလိုအပ်ပါ။
သင်ညှိနိုင်သည်-
- စီပီယူ။
- မှတ်ဉာဏ်။
- သိုလှောင်ခြင်း။
- တခြား။ သရေစာအတွက် အဆုံးမှာ ဒီအကြောင်းပြောမယ်။ ဥပမာအားဖြင့်၊ စွမ်းအင်ချွေတာရေးမူဝါဒကဲ့သို့သော ကန့်သတ်ချက်များသည်ပင်လျှင် အလွန်ခန့်မှန်းရခက်ပြီး အပျော်ရဆုံးနည်းလမ်းမဟုတ်သည့် စွမ်းဆောင်ရည်ကို ထိခိုက်စေနိုင်သည်။
PostgreSQL နှင့် ယေဘူယျအားဖြင့် ဒေတာဘေ့စ်၏ သီးခြားထူးခြားချက်များကား အဘယ်နည်း။ ပြဿနာမှာ သင်သည် မည်သည့် nut ကိုမဆို ပြုပြင်ပြောင်းလဲနိုင်ပြီး ကျွန်ုပ်တို့၏ စွမ်းဆောင်ရည် သိသိသာသာ တိုးတက်လာသည်ကို တွေ့မြင်ရခြင်း ဖြစ်ပါသည်။
ဟုတ်ကဲ့၊ အဲလို gadget တွေရှိပါတယ်၊ ဒါပေမယ့် database တစ်ခုဟာ ရှုပ်ထွေးတဲ့ အရာပါ။ ၎င်းသည် ဆာဗာတွင်ရှိသော အရင်းအမြစ်များအားလုံးနှင့် အပြန်အလှန် အကျိုးပြုပြီး အပြည့်အဝ အပြန်အလှန် တုံ့ပြန်ရန် နှစ်သက်သည်။ Oracle ၏ host OS ကိုအသုံးပြုပုံနှင့်ပတ်သက်သည့် လက်ရှိအကြံပြုချက်များကိုကြည့်ပါက၊ ၎င်းသည် မွန်ဂိုလီးယားအာကာသယာဉ်မှူးအကြောင်း ပြက်လုံးအတိုင်းဖြစ်နေလိမ့်မည်- ခွေးကို အစာကျွေးပြီး ဘာမှမထိဘဲနေပါ။ ဒေတာဘေ့စ်ကို အရင်းအမြစ်အားလုံးကို ပေးပါရစေ၊ ဒေတာဘေ့စ်ကိုယ်တိုင်က အရာအားလုံးကို ခွဲထုတ်ပါလိမ့်မယ်။
မူအရ၊ အခြေအနေအချို့သည် PostgreSQL နှင့်အတိအကျတူညီသည်။ ကွာခြားချက်မှာ ဒေတာဘေ့စ်သည် အရင်းအမြစ်အားလုံးကို သူ့ဘာသာသူ မယူနိုင်သေးသောကြောင့်၊ ဆိုလိုသည်မှာ သင်ကိုယ်တိုင် ခွဲခြမ်းစိပ်ရန် လိုအပ်သော Linux အဆင့်ရှိ တစ်နေရာရာတွင် ဖြစ်သည်။
အဓိက စိတ်ကူးမှာ ပစ်မှတ်တစ်ခုတည်းကို ရွေးပြီး ချိန်ညှိခြင်းကို စတင်ရန် မဟုတ်ဘဲ၊ ဥပမာ၊ memory၊ CPU သို့မဟုတ် ထိုကဲ့သို့သော အရာတစ်ခုခုကို ခွဲခြမ်းစိတ်ဖြာရန်နှင့် ၎င်းကို ကောင်းမွန်သော ပရိုဂရမ်မာများက ဖန်တီးပေးသော load ကို တတ်နိုင်သမျှ တိုးတက်အောင် ကြိုးစားရန်၊ ကျွန်ုပ်တို့၏အသုံးပြုသူများအပါအဝင် ကျွန်ုပ်တို့အတွက်။
ဒါက ဘာလဲဆိုတာ ရှင်းပြဖို့ ပုံတစ်ပုံပါ။ Linux OS buffer တစ်ခုရှိပြီး မျှဝေထားသော memory ရှိပြီး PostgreSQL shared ကြားခံများရှိပါသည်။ Oracle နှင့်မတူဘဲ PostgreSQL သည် kernel ကြားခံမှတဆင့်သာ တိုက်ရိုက်အလုပ်လုပ်သည်၊ ဆိုလိုသည်မှာ ဒစ်မှစာမျက်နှာတစ်ခုသည် ၎င်း၏မျှဝေထားသောမှတ်ဉာဏ်သို့ရောက်ရှိရန်အတွက် kernel ကြားခံနှင့်နောက်သို့သွားရမည်၊ တူညီသောအခြေအနေဖြစ်သည်။
Disks များသည် ဤစနစ်အောက်တွင် နေထိုင်ကြသည်။ ဒါကို disk တွေအဖြစ် ကျွန်တော်ဆွဲတယ်။ တကယ်တော့ RAID controller စတာတွေ ရှိနိုင်ပါတယ်။
ပြီးတော့ ဒီ input-output က တစ်နည်းမဟုတ် တစ်နည်း ဖြစ်ပျက်နေတာ။
PostgreSQL သည် ဂန္ထဝင်ဒေတာဘေ့စ်တစ်ခုဖြစ်သည်။ အထဲမှာ စာမျက်နှာတစ်ခုရှိတယ်။ စာမျက်နှာများကို အသုံးပြု၍ အဝင်နှင့်အထွက်အားလုံး ဖြစ်ပေါ်သည်။ ကျွန်ုပ်တို့သည် စာမျက်နှာများဖြင့် မှတ်ဉာဏ်အဖြစ် ဘလောက်များကို ပြုစုပျိုးထောင်နေပါသည်။ ဘာမှဖြစ်မလာဘူးဆိုရင်၊ အဲဒါတွေကို ဖတ်ရုံပဲ၊ ပြီးတော့ သူတို့ဟာ မျှဝေထားတဲ့ ကြားခံတွေကနေ တဖြည်းဖြည်းနဲ့ ဒီကက်ရှ်ကနေ ပျောက်ကွယ်သွားပြီး ဒစ်ပေါ်မှာ ပြန်တက်သွားကြပါတယ်။
တစ်ခုခုကို တစ်နေရာရာမှာ အစားထိုးရင် စာမျက်နှာတစ်ခုလုံးကို ညစ်ပတ်တယ်လို့ မှတ်ထားတယ်။ သူတို့ကို ဒီမှာ အပြာရောင်နဲ့ အမှတ်အသားပြုထားတယ်။ ဆိုလိုသည်မှာ ဤစာမျက်နှာကို ဘလောက်သိုလှောင်မှုဖြင့် ထပ်တူပြုရမည်ဟု ဆိုလိုသည်။ အဲဒါကို ညစ်ပတ်အောင် လုပ်လိုက်တာနဲ့ WAL မှာ ဝင်ခွင့်လုပ်တယ်။ အံ့သြစရာကောင်းတဲ့အခိုက်အတန့်မှာ စစ်ဆေးရေးဂိတ်လို့ခေါ်တဲ့ ဖြစ်စဉ်တစ်ခုရောက်လာတယ်။ ပြီးတော့ သူရောက်လာတဲ့ အချက်အလက်တွေကို ဒီမှတ်တမ်းမှာ မှတ်တမ်းတင်ထားတယ်။ ဆိုလိုသည်မှာ ဤမျှဝေထားသော ကြားခံများတွင် ထိုအချိန်က ဤနေရာတွင်ရှိနေသည့် ညစ်ပတ်သောစာမျက်နှာအားလုံးကို kernel ကြားခံမှတဆင့် fsync သုံးပြီး သိုလှောင်ဒစ်နှင့် ထပ်တူပြုထားသည်။
ဘာကြောင့် ဒီလိုလုပ်တာလဲ။ အကယ်၍ ကျွန်ုပ်တို့သည် လျှပ်စီးကြောင်းများ ဆုံးရှုံးသွားပါက၊ ဒေတာအားလုံး ဆုံးရှုံးသွားသည့် အခြေအနေကို ကျွန်ုပ်တို့ မရရှိခဲ့ပါ။ လူတိုင်းက ကျွန်ုပ်တို့အကြောင်းပြောခဲ့သည့် မြဲမြံသောမှတ်ဉာဏ်သည် ဒေတာဘေ့စ်သီအိုရီတွင် ယခုအချိန်အထိဖြစ်သည် - ဤသည်မှာ တောက်ပသောအနာဂတ်ဖြစ်သည်၊ သေချာပါသည်၊ ကျွန်ုပ်တို့ကြိုးစားပြီး ကျွန်ုပ်တို့နှစ်သက်သော၊ သို့သော် ယခုအခါ ၎င်းတို့သည် အနှုတ်နှစ် 20 တွင်နေထိုင်ကြသည်။ ပြီးတော့ ဒါတွေအားလုံးက စောင့်ကြည့်ဖို့လိုတယ်။
ပြီးတော့ သွင်းအားကို အမြင့်ဆုံးဖြစ်အောင် လုပ်ရမယ့်တာဝန်က အားလုံးကို မြန်မြန်ဆန်ဆန် ရွေ့လျားသွားအောင် ဒီအဆင့်တွေအားလုံးမှာ သေချာချိန်ညှိဖို့ပါပဲ။ Shared memory သည် အခြေခံအားဖြင့် page cache တစ်ခုဖြစ်သည်။ PostgreSQL တွင် ကျွန်ုပ်တို့သည် ရွေးချယ်ထားသော မေးခွန်းတစ်ခု သို့မဟုတ် တစ်ခုခုကို ပေးပို့ခဲ့ပြီး ၎င်းသည် ဤဒေတာကို ဒစ်ခ်မှ ပြန်လည်ရယူခဲ့သည်။ ၎င်းတို့သည် မျှဝေထားသော ကြားခံများဖြင့် အဆုံးသတ်ခဲ့သည်။ ထို့ကြောင့် ၎င်းကို ပိုမိုကောင်းမွန်စေရန်အတွက် မှတ်ဉာဏ်များစွာရှိရပါမည်။
ဤအရာအားလုံး ကောင်းမွန်မြန်ဆန်စွာ လုပ်ဆောင်နိုင်ရန်၊ အဆင့်တိုင်းတွင် လည်ပတ်မှုစနစ်ကို မှန်ကန်စွာ ပြင်ဆင်သတ်မှတ်ရန် လိုအပ်သည်။ သင့်တွင် အချို့နေရာများတွင် မညီမျှမှုများရှိနေပါက၊ သင်သည် မန်မိုရီများစွာကို ပြုလုပ်နိုင်သောကြောင့် မျှတသော ဟာ့ဒ်ဝဲကို ရွေးချယ်ပါ။
ပြီးတော့ ဒီအချက်တွေထဲက တစ်ခုစီကို ဖြတ်သန်းကြရအောင်။
ဤစာမျက်နှာများ အသွားအပြန်မြန်စေရန်၊ အောက်ပါတို့ကို အောင်မြင်ရန် လိုအပ်ပါသည်။
- ပထမဦးစွာ၊ သင်သည် Memory ကိုပိုမိုထိရောက်စွာလုပ်ဆောင်ရန်လိုအပ်သည်။
- ဒုတိယအနေဖြင့်၊ မှတ်ဉာဏ်မှစာမျက်နှာများ disk သို့သွားသောအခါဤအကူးအပြောင်းသည်ပိုမိုထိရောက်သင့်သည်။
- တတိယအနေနဲ့ ကောင်းမွန်တဲ့ disk တွေရှိရပါမယ်။
အကယ်၍ သင့်တွင် ဆာဗာတွင် 512 GB RAM ရှိပြီး ၎င်းအားလုံးသည် ကက်ရှ်မပါဘဲ SATA ဟာ့ဒ်ဒရိုက်ပေါ်တွင် အဆုံးသတ်ပါက၊ ထို့နောက် ဒေတာဘေ့စ်ဆာဗာတစ်ခုလုံးသည် ရွှေဖရုံသီးသာမက SATA မျက်နှာပြင်ပါရှိသော ရွှေဖရုံသီးတစ်လုံးအဖြစ်သို့ ပြောင်းလဲသွားမည်ဖြစ်သည်။ သင်တိုက်ရိုက်ပြေးလိမ့်မည်။ ပြီးတော့ မင်းကို ဘယ်အရာမှ ကယ်တင်မှာမဟုတ်ဘူး။
ပထမမှတ်ဉာဏ်နဲ့ ပတ်သက်ရင် ဘဝအတွက် အလွန်ခက်ခဲစေနိုင်တဲ့ အချက်သုံးချက်ရှိပါတယ်။
၎င်းတို့ထဲမှ ပထမဆုံးမှာ NUMA ဖြစ်သည်။ NUMA သည် စွမ်းဆောင်ရည် မြှင့်တင်ရန် ဖန်တီးထားသည့် အရာတစ်ခု ဖြစ်သည်။ အလုပ်တာဝန်ပေါ်မူတည်၍ မတူညီသော အရာများကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်နိုင်သည်။ ၎င်း၏လက်ရှိပုံစံအသစ်တွင်၊ ၎င်းသည် page cache shared buffers ကိုအလေးအနက်ထားအသုံးပြုသည့်ဒေတာဘေ့စ်ကဲ့သို့သော application များအတွက်အလွန်မကောင်းပါ။
အတိုချုပ်ပြောရရင်။ NUMA တွင် တစ်စုံတစ်ခု မှားယွင်းနေပါက သင်မည်သို့ပြောနိုင်မည်နည်း။ သင့်တွင် မနှစ်မြို့ဖွယ်ကောင်းသော ခေါက်သံများ ရှိသည်၊ ရုတ်တရက် အချို့သော CPU များ လွန်ကဲနေပါသည်။ တစ်ချိန်တည်းမှာပင် သင်သည် PostgreSQL တွင် မေးခွန်းများကို ခွဲခြမ်းစိတ်ဖြာပြီး ထိုနေရာတွင် အလားတူမည်သည့်အရာမှ မရှိသည်ကို သင်တွေ့မြင်ရသည်။ ဤမေးခွန်းများသည် CPU အလွန်အကျွံမဖြစ်သင့်ပါ။ ဒါကို အချိန်အကြာကြီး ဖမ်းလို့ရတယ်။ PostgreSQL အတွက် NUMA ကို configure လုပ်နည်းအစကတည်းက မှန်ကန်သောအကြံပြုချက်ကို အသုံးပြုရန် ပိုမိုလွယ်ကူသည်။
တကယ်ဘာဖြစ်နေတာလဲ? NUMA သည် Non-Uniform Memory Access ကို ကိုယ်စားပြုသည်။ ဘာအချက်လဲ။ သင့်တွင် CPU တစ်ခုရှိပြီး ၎င်းဘေးတွင် ၎င်း၏စက်တွင်းမှတ်ဉာဏ်ရှိသည်။ ပြီးတော့ ဒီမှတ်ဉာဏ် အပြန်အလှန်ချိတ်ဆက်မှုက တခြား CPU တွေကနေ Memory ကို ဆွဲထုတ်နိုင်ပါတယ်။
ပြေးရင်၊ numactl --hardwareဒါဆိုရင်တော့ ဒီလောက်ကြီးတဲ့ စာရွက်ကို ရလိမ့်မယ်။ ပမာအားဖြင့်၊ အကွာအဝေးကွင်းပြင်တစ်ခုရှိလိမ့်မည်။ ဂဏန်း 10-20 ၊ အဲလိုမျိုးရှိမယ်။ ဤနံပါတ်များသည် ဤအဝေးထိန်းမှတ်ဉာဏ်ကို ကောက်ယူပြီး စက်တွင်းအသုံးပြုရန် ခုန်ပေါက်အရေအတွက်ထက် မပိုပါ။ မူအရ စိတ်ကူးကောင်းတယ်။ ၎င်းသည် အလုပ်တာဝန်များစွာအောက်တွင် စွမ်းဆောင်ရည်ကို ကောင်းမွန်စေသည်။
ယခု သင့်တွင် CPU တစ်လုံးရှိပြီး ၎င်း၏ local memory ကို အသုံးပြုရန် ပထမဆုံးကြိုးစားကာ တစ်စုံတစ်ခုအတွက် အပြန်အလှန်ချိတ်ဆက်မှုမှတစ်ဆင့် အခြား memory တစ်ခုကို ဆွဲထုတ်ရန် ကြိုးစားနေသည်ဟု မြင်ယောင်ကြည့်ပါ။ ပြီးတော့ ဒီ CPU က မင်းရဲ့ PostgreSQL စာမျက်နှာ ကက်ရှ် တစ်ခုလုံးကို ရတယ်၊ ဒါပဲ၊ တချို့ ဂစ်ဂါဘိုက်တွေ။ အဘယ်ကြောင့်ဆိုသော် CPU တွင် ထို module ကိုယ်တိုင်၌ memory အနည်းငယ်သာ ရှိသောကြောင့် သင်သည် အမြဲတမ်း အဆိုးဆုံး အခြေအနေတွင် ရှိနေသည်။ ဝန်ဆောင်မှုပေးသော မမ်မိုရီအားလုံးသည် ဤအပြန်အလှန်ချိတ်ဆက်မှုများမှတဆင့် သွားပါသည်။ နှေးကွေးပြီး ဝမ်းနည်းစရာတွေ ထွက်လာတယ်။ နှင့် ဤ node ကို ဝန်ဆောင်မှုပေးသော သင်၏ပရိုဆက်ဆာသည် အဆက်မပြတ် လွန်နေပါသည်။ ပြီးတော့ ဒီမှတ်ဉာဏ်ရဲ့ ဝင်ရောက်ချိန်က ဆိုးတယ်၊ နှေးတယ်။ ဤသည်မှာ ဒေတာဘေ့စ်တစ်ခုအတွက် သင်အသုံးပြုနေပါက သင်မလိုလားအပ်သော အခြေအနေဖြစ်သည်။
ထို့ကြောင့်၊ ဒေတာဘေ့စ်အတွက် ပိုမိုမှန်ကန်သောရွေးချယ်မှုမှာ Linux လည်ပတ်မှုစနစ်တွင် မည်သည့်အရာဖြစ်နေသည်ကို လုံးဝမသိစေရန်ဖြစ်သည်။ ဒါမှ Memory ကိုဝင်နိုင်မှာပါ။
အဲဒီလို့ဘာဖြစ်လို့? ဒါဟာ တခြားနည်းလမ်းဖြစ်သင့်တယ်လို့ ထင်ပါတယ်။ ၎င်းသည် ရိုးရှင်းသော အကြောင်းပြချက်တစ်ခုကြောင့် ဖြစ်ပေါ်လာသည်- ကျွန်ုပ်တို့သည် စာမျက်နှာ cache အတွက် မှတ်ဉာဏ်များစွာ လိုအပ်သည် - ဆယ်ဂဏန်း၊ ရာနှင့်ချီသော ဂစ်ဂါဘိုက်များ။
ကျွန်ုပ်တို့သည် ဤအရာအားလုံးကို ခွဲဝေချထားပြီး ကျွန်ုပ်တို့၏ဒေတာကို ထိုနေရာတွင် သိမ်းဆည်းထားပါက၊ ထို့နောက် ကက်ရှ်ကိုအသုံးပြုခြင်းမှ ရရှိသည့် အကျိုးကျေးဇူးသည် ထိုကဲ့သို့ ရှုပ်ထွေးလှသော memory သို့ ဝင်ရောက်ခြင်းမှ ရရှိခြင်းထက် သိသိသာသာ ကြီးမားမည်ဖြစ်သည်။ ထို့အပြင် ကျွန်ုပ်တို့သည် NUMA ကိုအသုံးပြု၍ မှတ်ဉာဏ်ကိုပိုမိုထိရောက်စွာဝင်ရောက်နိုင်သည်ဟူသောအချက်နှင့်နှိုင်းယှဉ်ပါကကျွန်ုပ်တို့အဆမတန်အကျိုးရှိမည်ဖြစ်ပါသည်။
ထို့ကြောင့်၊ ယခုအချိန်တွင် ဤနေရာတွင် ချဉ်းကပ်မှု နှစ်ခုရှိပါသည်၊ တောက်ပသောအနာဂတ်ကို ရောက်ရှိလာသည်နှင့် ဒေတာဘေ့စ်ကိုယ်တိုင်က မည်သည့် CPU များကို လုပ်ဆောင်နေပြီး မည်သည့်နေရာမှ တစ်စုံတစ်ရာကို ဆွဲထုတ်ရမည်ကို မခန့်မှန်းနိုင်ပါ။
ထို့ကြောင့်၊ မှန်ကန်သောနည်းလမ်းမှာ NUMA ကို လုံးဝပိတ်ရန်ဖြစ်သည်။ဥပမာ၊ reboot လုပ်တဲ့အခါ။ ကိစ္စအများစုတွင်၊ အောင်ပွဲများသည် မည်သည့်အရာက ပိုကောင်းသနည်းဟူသော မေးခွန်းသည် လုံး၀မပေါ်ပေါက်နိုင်သော အတိုင်းအတာတစ်ခုအထိဖြစ်သည်။
အခြားရွေးချယ်စရာတစ်ခုရှိသည်။ ကျွန်ုပ်တို့သည် ၎င်းကို ပထမတစ်ခုထက် မကြာခဏအသုံးပြုသည်၊ အကြောင်းမှာ ဖောက်သည်တစ်ဦးသည် ကျွန်ုပ်တို့ထံ အကူအညီတောင်းသည့်အခါ ဆာဗာကို ပြန်လည်စတင်ခြင်းသည် သူ့အတွက် ကြီးမားသောကိစ္စဖြစ်သောကြောင့် ဖြစ်သည်။ သူ့မှာ စီးပွားရေးရှိတယ်။ ပြီးတော့ သူတို့က NUMA ကြောင့် ပြဿနာတွေ ကြုံရတယ်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ၎င်းကို ပြန်လည်ဖွင့်ခြင်းထက် ထိုးဖောက်နည်းနည်းများဖြင့် ပိတ်ရန် ကြိုးစားသော်လည်း ၎င်းကို ပိတ်ထားကြောင်း စစ်ဆေးရန် သတိထားပါ။ အတွေ့အကြုံကပြသထားသည့်အတိုင်း၊ ကျွန်ုပ်တို့သည် မိဘ PostgreSQL လုပ်ငန်းစဉ်တွင် NUMA ကိုပိတ်ထားသည်မှာ ကောင်းပါတယ်၊ သို့သော် ၎င်းသည် အလုပ်ဖြစ်ရန် လုံးဝမလိုအပ်ပါ။ သူမ တကယ်ပဲ မီးပိတ်သွားတာကို စစ်ဆေးကြည့်ဖို့ လိုပါတယ်။
Robert Haas ရဲ့ ကောင်းမွန်တဲ့ ပို့စ်တစ်ခုရှိပါတယ်။ ၎င်းသည် PostgreSQL committers များထဲမှတစ်ခုဖြစ်သည်။ အဆင့်နိမ့် giblets အားလုံး၏ အဓိက developer များထဲမှ တစ်ဦး။ အကယ်၍ သင်သည် ဤပို့စ်မှ လင့်ခ်များကို လိုက်နာပါက၊ NUMA သည် လူများအတွက် ဘဝခက်ခဲစေသည့်အကြောင်း ရောင်စုံဇာတ်လမ်းများစွာကို ဖော်ပြပါသည်။ ကြည့်ပါ၊ ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်ကို ကောင်းမွန်စွာအလုပ်လုပ်နိုင်စေရန်အတွက် ဆာဗာတွင် configure လုပ်ရန် လိုအပ်သည့်အရာများ၏ system administrator checklist ကို လေ့လာကြည့်ပါ။ ဤဆက်တင်များသည် အလွန်ကောင်းမွန်မည်မဟုတ်သောကြောင့် ဤဆက်တင်များကို ချရေးပြီး စစ်ဆေးရန် လိုအပ်ပါသည်။
၎င်းသည် ကျွန်ုပ်ပြောမည့် ဆက်တင်များအားလုံးနှင့် သက်ဆိုင်ကြောင်း သတိပြုပါ။ သို့သော် အများအားဖြင့် ဒေတာဘေ့စ်များကို အမှားခံနိုင်ရည်ရှိရန်အတွက် master-slave မုဒ်တွင် စုဆောင်းထားသည်။ တစ်နေ့မှာ မင်းမတော်တဆမှုတစ်ခုကြုံပြီး ကျွန်ဆီပြောင်းပြီး သခင်ဖြစ်လာမှာဖြစ်လို့ ဒီဆက်တင်တွေကို ကျွန်မှာပြုလုပ်ဖို့ မမေ့ပါနဲ့။
အရေးပေါ်အခြေအနေမှာ၊ အရာအားလုံးက အရမ်းဆိုးလာတဲ့အခါ သင့်ဖုန်းက အဆက်မပြတ်မြည်နေပြီး သင့်သူဌေးက တုတ်ကြီးနဲ့ ပြေးလာတာ၊ စစ်ဆေးဖို့ စဉ်းစားဖို့ အချိန်မရှိတော့ပါဘူး။ ပြီးတော့ ရလဒ်တွေက တော်တော်ဆိုးသွားနိုင်တယ်။
နောက်တစ်ခုက စာမျက်နှာတွေ ကြီးမားတယ်။ ကြီးမားသော စာမျက်နှာများသည် သီးခြားစီ စမ်းသပ်ရန် ခက်ခဲပြီး ၎င်းကို လုပ်ဆောင်နိုင်သည့် စံနှုန်းများ ရှိနေသော်လည်း ထိုသို့ လုပ်ဆောင်ရာတွင် အဓိပ္ပါယ်မရှိပါ။ ၎င်းတို့သည် Google တွင်လွယ်ကူသည်။
ဘာအချက်လဲ။ သင့်တွင် RAM အများအပြားပါရှိသော အလွန်စျေးကြီးသောဆာဗာတစ်ခု၊ ဥပမာအားဖြင့် 30 GB ထက်ပိုပါသည်။ ကြီးမားတဲ့ စာမျက်နှာတွေကို မသုံးပါဘူး။ ဆိုလိုသည်မှာ သင့်တွင် မမ်မိုရီအသုံးပြုမှု သတ်မှတ်ချက်များတွင် သေချာပေါက် အကျုံးဝင်ပါသည်။ ပြီးတော့ ဒီခေါင်းပေါ်က အပျော်ဆုံးနဲ့ ဝေးတယ်။
အဲဒီလို့ဘာဖြစ်လို့? ဒါဆို ဘာဖြစ်နေတာလဲ? Operating System သည် Memory ကို သေးငယ်သောအပိုင်းများဖြင့် ခွဲဝေပေးသည်။ အရမ်းအဆင်ပြေတယ်၊ သမိုင်းကြောင်းအရ ဘယ်လိုဖြစ်တာလဲ။ ကျွန်ုပ်တို့ အသေးစိတ်လေ့လာပါက၊ OS သည် virtual လိပ်စာများကို ရုပ်ပိုင်းဆိုင်ရာများအဖြစ် ဘာသာပြန်ပေးရမည်ဖြစ်သည်။ ဤလုပ်ငန်းစဉ်သည် အရိုးရှင်းဆုံးမဟုတ်သောကြောင့် OS သည် Translation Lookaside Buffer (TLB) တွင် ဤလုပ်ဆောင်ချက်၏ရလဒ်ကို သိမ်းဆည်းထားသည်။
TLB သည် ကက်ရှ်တစ်ခုဖြစ်သောကြောင့်၊ ကက်ရှ်တစ်ခုတွင် ပေါက်ဖွားလာသော ပြဿနာအားလုံးသည် ဤအခြေအနေတွင် ဖြစ်ပေါ်လာသည်။ ပထမဦးစွာ သင့်တွင် RAM အများအပြားရှိပြီး ၎င်းအားလုံးကို အတုံးသေးသေးလေးများဖြင့် ခွဲဝေထားပါက ၎င်းကြားခံသည် အလွန်ကြီးမားလာသည်။ ကက်ရှ်သည် ကြီးမားပါက၊ ၎င်းကိုရှာဖွေခြင်းသည် နှေးကွေးသည်။ Overhead သည် ကျန်းမာရေးနှင့် ညီညွတ်ပြီး ၎င်းကိုယ်တိုင် နေရာလွတ်ယူသည်၊ ဆိုလိုသည်မှာ RAM ကို မှားယွင်းမှုတစ်ခုခုကြောင့် သုံးစွဲနေပါသည်။ ဒီတစ်ခါ။
နှစ်ခု - ထိုသို့သောအခြေအနေမျိုးတွင် cache များပိုမိုကြီးထွားလေ၊ သင့်တွင် cache misses ရှိနိုင်ခြေပိုများလေဖြစ်သည်။ နှင့် ၎င်း၏အရွယ်အစား တိုးလာသည်နှင့်အမျှ ဤ cache ၏ ထိရောက်မှု လျင်မြန်စွာ ကျဆင်းလာသည်။ ထို့ကြောင့်၊ လည်ပတ်မှုစနစ်များသည် ရိုးရှင်းသောနည်းလမ်းတစ်ခုဖြင့် ပေါ်ပေါက်လာခဲ့သည်။ ၎င်းကို Linux တွင် အသုံးပြုနေသည်မှာ ကြာပါပြီ။ မကြာသေးမီက FreeBSD တွင်ပေါ်လာသည်။ ဒါပေမယ့် Linux အကြောင်းပြောနေတာ။ ဤအရာများသည် ကြီးမားသော စာမျက်နှာများဖြစ်သည်။
ဤနေရာတွင် အိုင်ဒီယာတစ်ခုအနေဖြင့် ကြီးမားသောစာမျက်နှာများကို Oracle နှင့် IBM အပါအဝင် အသိုင်းအဝိုင်းများမှ အစပိုင်းတွင် တွန်းအားပေးခဲ့သည်၊ ဆိုလိုသည်မှာ ဒေတာဘေ့စ်ထုတ်လုပ်သူများကလည်း ၎င်းသည် ဒေတာဘေ့စ်များအတွက် အသုံးဝင်မည်ဟု ပြင်းပြင်းထန်ထန် တွေးတောသင့်ပါသည်။
၎င်းကို PostgreSQL နှင့် မည်သို့မိတ်ဆွေဖွဲ့နိုင်မည်နည်း။ ပထမဦးစွာ၊ ကြီးမားသောစာမျက်နှာများကို Linux kernel တွင်ဖွင့်ထားရပါမည်။
ဒုတိယအနေနှင့်၊ ၎င်းတို့ကို sysctl ကန့်သတ်ချက်ဖြင့် အတိအလင်းသတ်မှတ်ထားရမည် - မည်မျှရှိသနည်း။ ဤနံပါတ်များသည် ဆာဗာဟောင်းအချို့မှဖြစ်သည်။ ကြီးမားသောစာမျက်နှာများသည် ထိုနေရာတွင် အံဝင်ခွင်ကျဖြစ်စေရန်အတွက် သင့်တွင် မျှဝေထားသည့်ကြားခံမည်မျှရှိသည်ကို သင်တွက်ချက်နိုင်သည်။
အကယ်၍ သင့်ဆာဗာတစ်ခုလုံးကို PostgreSQL အတွက် ရည်စူးထားလျှင် ကောင်းသောအစမှတ်မှာ မျှဝေထားသောကြားခံအတွက် RAM ၏ 25% ကို ခွဲဝေပေးရန် သို့မဟုတ် သင့်ဒေတာဘေ့စ်သည် ဤ 75% တွင် ကျိန်းသေအံဝင်မည်ဟု သေချာပါက 75% ကို ခွဲဝေပေးရန်ဖြစ်သည်။ စမှတ်တစ်။ အကယ်၍ သင့်တွင် 256 GB RAM ရှိပါက၊ ထို့ကြောင့် သင့်တွင် 64 GB ကြီးမားသော buffers ရှိသည်ကို စဉ်းစားပါ။ အနားသတ်အချို့ဖြင့် အနီးစပ်ဆုံး တွက်ချက်ပါ - ဤကိန်းဂဏန်းကို အဘယ်သို့ သတ်မှတ်သင့်သနည်း။
ဗားရှင်း 9.2 မတိုင်မီ (ဗားရှင်း 8.2 မှစ၍ ကျွန်ုပ်မမှားပါက)၊ ၎င်းသည် ပြင်ပအဖွဲ့အစည်းစာကြည့်တိုက်ကို အသုံးပြု၍ PostgreSQL ကို ကြီးမားသောစာမျက်နှာများနှင့် ချိတ်ဆက်နိုင်သည်။ ပြီးတော့ ဒါကို အမြဲလုပ်သင့်တယ်။ ပထမဦးစွာ၊ ကြီးမားသောစာမျက်နှာများကိုမှန်ကန်စွာခွဲဝေပေးနိုင်ရန် kernel ကိုလိုအပ်သည်။ ဒုတိယအနေနဲ့၊ သူတို့နဲ့အလုပ်လုပ်တဲ့ application ကသူတို့ကိုသုံးနိုင်စေဖို့ပါ။ ဒီနည်းကိုပဲ သုံးမှာ မဟုတ်ပါဘူး။ PostgreSQL သည် စနစ် 5 စတိုင်တွင် မမ်မိုရီကို ခွဲဝေပေးသည့်အတွက်၊ ၎င်းကို libhugetlbfs ဖြင့် လုပ်ဆောင်နိုင်သည် - ဤသည်မှာ စာကြည့်တိုက်၏ အမည်အပြည့်အစုံဖြစ်သည်။
9.3 တွင်၊ မမ်မိုရီနှင့်အလုပ်လုပ်သောအခါ PostgreSQL စွမ်းဆောင်ရည်ကို မြှင့်တင်ခဲ့ပြီး စနစ် 5 မှတ်ဉာဏ်ခွဲဝေမှုနည်းလမ်းကို စွန့်လွှတ်ခဲ့သည်။ စက်တစ်လုံးတွင် PostgreSQL instances နှစ်ခုကို သင်အသုံးပြုရန်ကြိုးစားသောကြောင့် လူတိုင်းသည် အလွန်ပျော်ရွှင်ခဲ့ကြပြီး၊ ကျွန်ုပ်တွင် မျှဝေမှတ်ဉာဏ် လုံလောက်မှုမရှိကြောင်း သူကဆိုသည်။ ပြီးတော့ သူက sysctl ကိုပြင်ဖို့လိုတယ်ပြောတယ်။ သင် reboot လုပ်ရန် လိုအပ်နေသေးသော sysctl တစ်ခုရှိပါသည်၊ ယေဘူယျအားဖြင့်၊ လူတိုင်း ပျော်ရွှင်ကြသည်။ သို့သော် mmap မမ်မိုရီခွဲဝေမှုသည် ကြီးမားသောစာမျက်နှာများကို အသုံးပြုခြင်းကို ပျက်ပြားစေသည်။ ကျွန်ုပ်တို့၏ဖောက်သည်အများစုသည် ကြီးမားသောမျှဝေထားသောကြားခံများကို အသုံးပြုကြသည်။ ထို့အပြင် 9.3 သို့မပြောင်းရန် ကျွန်ုပ်တို့ ပြင်းပြင်းထန်ထန် အကြံပြုထားပါသည်၊ အကြောင်းမှာ အထက်ဖော်ပြပါတွင် ကောင်းမွန်သော ရာခိုင်နှုန်းများဖြင့် စတင်တွက်ချက်နေသောကြောင့် ဖြစ်သည်။
ဒါပေမယ့် အသိုင်းအဝိုင်းက ဒီပြဿနာကို အာရုံစိုက်ခဲ့ပြီး 9.4 မှာ သူတို့ဟာ ဒီဖြစ်ရပ်ကို အလွန်ကောင်းမွန်စွာ ပြန်လည်လုပ်ဆောင်ခဲ့ပါတယ်။ 9.4 တွင် သင်စမ်းသုံးနိုင်၊ အဖွင့်အပိတ်လုပ်နိုင်သည့် ဘောင်တစ်ခုသည် postgresql.conf တွင်ပေါ်လာသည်။
ကြိုးစားခြင်းသည် အလုံခြုံဆုံးရွေးချယ်မှုဖြစ်သည်။ PostgreSQL စတင်သောအခါ၊ ၎င်းသည် မျှဝေထားသောမှတ်ဉာဏ်ကို ခွဲဝေပေးသောအခါ၊ ၎င်းသည် ဤမှတ်ဉာဏ်ကို ကြီးမားသောစာမျက်နှာများမှ ရယူရန် ကြိုးစားသည်။ အလုပ်မဖြစ်ပါက၊ ၎င်းသည် ပုံမှန်ရွေးချယ်မှုသို့ ပြန်သွားပါမည်။ အကယ်၍ သင့်တွင် FreeBSD သို့မဟုတ် Solaris ရှိပါက သင်စမ်းသုံးကြည့်နိုင်သည်၊ ၎င်းသည် အမြဲတမ်း ဘေးကင်းပါသည်။
ဖွင့်ထားလျှင် ကြီးမားသော စာမျက်နှာများမှ မရွေးချယ်နိုင်ပါက ၎င်းသည် ရိုးရိုးရှင်းရှင်း မစတင်နိုင်ပါ။ ဒီမှာ ဘယ်သူနဲ့ ဘယ်ဟာ ပိုကောင်းလဲ ဆိုတာ သိပြီးသားပါ။ ဒါပေမယ့် ကြိုးစားပြီးပြီဆိုရင်တော့ error တွေအတွက် နေရာအများကြီးရှိလို့ သင်မီးမောင်းထိုးပြဖို့ လိုအပ်တာတွေ တကယ်ရှိမရှိ စစ်ဆေးကြည့်ပါ။ လောလောဆယ် ဤလုပ်ဆောင်ချက်သည် Linux တွင်သာ အလုပ်လုပ်ပါသည်။
မသွားခင် နောက်ထပ်မှတ်စုလေးတစ်ခု။ ဖောက်ထွင်းမြင်ရသော ကြီးမားသောစာမျက်နှာများသည် PostgreSQL အကြောင်းမဟုတ်သေးပါ။ သူသည် ၎င်းတို့ကို ပုံမှန်အသုံးမပြုနိုင်ပါ။ ထိုကဲ့သို့ အလုပ်တာဝန်အတွက် ဖောက်ထွင်းမြင်ရသော ကြီးမားသော စာမျက်နှာများနှင့်အတူ၊ မျှဝေထားသော မမ်မိုရီ၏ ကြီးမားသောအပိုင်းကို လိုအပ်သောအခါတွင် အကျိုးကျေးဇူးများသည် အလွန်ကြီးမားသော ပမာဏဖြင့်သာ ရရှိပါသည်။ သင့်တွင် terabytes Memory ရှိပါက ၎င်းသည် စတင်အသုံးပြုနိုင်မည်ဖြစ်သည်။ နေ့စဉ်သုံး အပလီကေးရှင်းများအကြောင်း ပြောနေလျှင် သင့်စက်တွင် မမ်မိုရီ 32၊ 64၊ 128၊ 256 GB ရှိသည်ဆိုလျှင် ပုံမှန်အတိုင်း ကြီးမားသော စာမျက်နှာများသည် OK ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် Transparent ကို ပိတ်လိုက်ပါသည်။
မှတ်ဉာဏ်ရဲ့ နောက်ဆုံးအချက်က အသီးအနှံနဲ့ တိုက်ရိုက်မသက်ဆိုင်ပါဘူး၊ ဒါဟာ သင့်ဘဝကို အမှန်တကယ် ပျက်စီးစေနိုင်ပါတယ်။ ဆာဗာသည် အဆက်မပြတ် လဲလှယ်နေသည်ဟူသောအချက်ကြောင့် ဖြတ်သန်းမှုအားလုံးသည် ကြီးမားစွာ သက်ရောက်မှုရှိမည်ဖြစ်သည်။
နည်းလမ်းများစွာဖြင့် ဤအရာသည် အလွန်မနှစ်မြို့ဖွယ်ဖြစ်လိမ့်မည်။ အဓိက ပြဿနာမှာ ခေတ်မီ kernels များသည် အဟောင်း Linux kernels များနှင့် အနည်းငယ် ကွဲပြားနေခြင်းကြောင့် ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော်၊ ကျွန်ုပ်တို့သည် swap နှင့်အလုပ်တစ်မျိုးမျိုးအကြောင်းပြောသောအခါတွင်၊ ၎င်းသည် OOM-လူသတ်သမား၏အချိန်မတန်မီရောက်ရှိခြင်းနှင့်အဆုံးသတ်သောကြောင့်၊ ဤအရာသည်ရှေ့ဆက်ရန်အတော်လေးမနှစ်မြို့စရာဖြစ်သည်။ အချိန်မီရောက်မလာဘဲ PostgreSQL ကို ကျဆင်းသွားစေသည့် OOM-လူသတ်သမားသည် မနှစ်မြို့ဖွယ်ဖြစ်သည်။ ဒီအကြောင်းကို လူတိုင်းသိလိမ့်မယ်၊ ဆိုလိုတာကတော့ နောက်ဆုံးအသုံးပြုသူအထိပါပဲ။
ဘာဖြစ်တာလဲ? သင့်တွင် RAM ပမာဏများစွာ ရှိပြီး အရာအားလုံး ကောင်းမွန်စွာ အလုပ်လုပ်ပါသည်။ သို့သော် အကြောင်းတစ်ခုခုကြောင့် ဆာဗာသည် လဲလှယ်မှုတွင် ဆိုင်းငံ့ထားကာ ယင်းကြောင့် နှေးကွေးသွားသည်။ မှတ်ဉာဏ်တွေ အများကြီးရှိပုံရတယ်၊ ဒါပေမယ့် ဒီလိုဖြစ်လာတယ်။
ယခင်က၊ ကျွန်ုပ်တို့သည် vm.swappiness ကို သုညသို့ သတ်မှတ်ရန် အကြံပြုထားသည်၊ ဆိုလိုသည်မှာ swap ကို ပိတ်ရန်။ ယခင်က 32 GB RAM နှင့် သက်ဆိုင်သော မျှဝေထားသော ကြားခံများသည် ပမာဏကြီးမားသည်ဟု ထင်ရသည်။ လဲလှယ်ခြင်း၏ အဓိကရည်ရွယ်ချက်မှာ ကျွန်ုပ်တို့ ပြုတ်ကျပါက အပေါ်ယံမြေလွှာကို ပစ်ချရန် နေရာတစ်ခုရှိရန်ဖြစ်သည်။ အထူးတလည် မပြည့်စုံတော့ပါ။ ပြီးတော့ ဒီကျောက်ကပ်ကို မင်းဘာလုပ်မလဲ။ ဤသည်မှာ အဘယ်ကြောင့် လဲလှယ်ရန် လိုအပ်သနည်း၊ အထူးသဖြင့် ထိုသို့သော အရွယ်အစားကို ရှင်းရှင်းလင်းလင်း မသိရသော အလုပ်ဖြစ်သည်။
သို့သော် ပိုမိုခေတ်မီသော၊ ဆိုလိုသည်မှာ၊ kernel ၏တတိယဗားရှင်းတွင်၊ အမူအကျင့်များ ပြောင်းလဲသွားပါသည်။ အကယ်၍ သင်သည် swap ကို သုညဟု သတ်မှတ်ပါက၊ ဆိုလိုသည်မှာ ၎င်းကို ပိတ်ပါ၊ ထို့နောက် RAM အချို့ ကျန်နေသေးလျှင်ပင်၊ အပြင်းထန်ဆုံး စားသုံးသူများကို သတ်ရန်အတွက် OOM killer သည် သင့်ထံ ရောက်ရှိလာမည်ဖြစ်သည်။ ထိုကဲ့သို့ အလုပ်တာဝန်ဖြင့်ကျွန်ုပ်တို့ အနည်းငယ်ကျန်နေသေးသည်ဟု သူစဉ်းစားမိမည်ဖြစ်သောကြောင့်၊ စနစ်လုပ်ငန်းစဉ်ကို နှိမ့်ချရန်မဟုတ်ဘဲ အရေးမကြီးသည့်အရာတစ်ခုကို ဖြတ်တောက်ရန် ခုန်ထွက်ပါမည်။ ဤအရေးကြီးသောနည်းသည် မျှဝေထားသောမှတ်ဉာဏ်၏ အကြိတ်အနယ်အသုံးပြုသူဖြစ်သည့် ပို့စ်မာစတာဖြစ်သည်။ ပြီးမှ အခြေခံကို ပြန်ပြင်စရာ မလိုရင် ကောင်းလိမ့်မယ်။
ထို့ကြောင့်၊ ယခုမူရင်း၊ ကျွန်ုပ်မှတ်မိသလောက်၊ ဖြန့်ဝေမှုအများစုသည် 6 ဝန်းကျင်တွင်ရှိသည်၊ ဆိုလိုသည်မှာ memory မည်မျှကျန်သည်ပေါ်မူတည်၍ swap ကိုစတင်အသုံးပြုသင့်သနည်း။ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် လက်တွေ့ကျကျအားဖြင့် ၎င်းကိုပိတ်ထားသော်လည်း မမျှော်လင့်ဘဲရောက်လာပြီး အားလုံးကိုသတ်ခဲ့သော OOM-လူသတ်သမားကဲ့သို့တူညီသောအကျိုးသက်ရောက်မှုများကိုမပေးသောကြောင့် vm.swappiness = 1 ကိုသတ်မှတ်ရန် ကျွန်ုပ်တို့အကြံပြုထားပါသည်။
နောက်တစ်ခုကဘာလဲ? ဒေတာဘေ့စ်များ၏ စွမ်းဆောင်ရည်အကြောင်း ပြောဆိုပြီး ဒစ်များဆီသို့ ဖြည်းဖြည်းချင်း ရွေ့လျားလာသောအခါ လူတိုင်းသည် ၎င်းတို့၏ ခေါင်းများကို ဖမ်းဆုပ်လာကြသည်။ အဘယ်ကြောင့်ဆိုသော် ဒစ်ခ်သည် နှေးကွေးပြီး မှတ်ဉာဏ် မြန်သည်ဟူသော အမှန်တရားသည် ငယ်စဉ်ကပင် လူတိုင်းနှင့် ရင်းနှီးသောကြောင့် ဖြစ်သည်။ ဒေတာဘေ့စ်တွင် disk စွမ်းဆောင်ရည်ပြဿနာများရှိမည်ကိုလူတိုင်းသိသည်။
စစ်ဆေးရေးဂိတ်များနှင့် ဆက်စပ်နေသော အဓိက PostgreSQL စွမ်းဆောင်ရည် ပြဿနာသည် ဒစ်ခ်နှေးသောကြောင့် မဖြစ်ပေါ်ပါ။ Memory နှင့် Disk Bandwidth သည် မမျှတသောကြောင့် ဖြစ်နိုင်သည်။ သို့သော်၊ ၎င်းတို့သည် မတူညီသောနေရာများတွင် ဟန်ချက်မညီနိုင်ပေ။ PostgreSQL ကို ပြုပြင်မွမ်းမံထားခြင်း၊ OS ကို မစီစဉ်ထား၊ ဟာ့ဒ်ဝဲကို မပြင်ဆင်ထားဘဲ ဟာ့ဒ်ဝဲ မမှန်ပါ။ ထို့အပြင် အရာအားလုံးသည် ဖြစ်သင့်သည်အတိုင်းသာ ဖြစ်ပါက၊ ဆိုလိုသည်မှာ ဝန်မရှိခြင်း သို့မဟုတ် ဆက်တင်များနှင့် ဟာ့ဒ်ဝဲများကို ကောင်းမွန်စွာ ရွေးချယ်ထားမှသာ ဤပြဿနာသည် ဖြစ်ပွားမည်မဟုတ်ပါ။
အဲဒါက ဘာနဲ့ ဘယ်လိုပုံစံလဲ။ များသောအားဖြင့် PostgreSQL နှင့်အလုပ်လုပ်သူများသည် ဤကိစ္စရပ်သို့ တစ်ကြိမ်ထက်ပို၍ ဝင်ရောက်လာကြသည်။ ရှင်းပြပါ့မယ်။ ကျွန်တော်ပြောခဲ့သည့်အတိုင်း PostgreSQL သည် ညစ်ညမ်းသောစာမျက်နှာများကို မျှဝေထားသော memory တွင် disk သို့ စွန့်ပစ်ရန် စစ်ဆေးရေးဂိတ်များကို အခါအားလျော်စွာ ပြုလုပ်ပါသည်။ အကယ်၍ ကျွန်ုပ်တို့တွင် မျှဝေထားသော မှတ်ဉာဏ်ပမာဏ များပြားပါက၊ စစ်ဆေးရေးဂိတ်သည် ဤစာမျက်နှာများကို fsync ဖြင့် စွန့်ပစ်သောကြောင့် ဒစ်ခ်ပေါ်တွင် ပြင်းထန်သော အကျိုးသက်ရောက်မှုများ စတင်လာသည်။ ၎င်းသည် kernel ကြားခံသို့ရောက်ရှိပြီး fsync ကိုအသုံးပြု၍ disk များသို့စာရေးသည်။ အကယ်၍ ဤလုပ်ငန်း၏ ပမာဏသည် ကြီးမားပါက၊ ဒစ်များကို အလွန်ကြီးမားစွာ အသုံးပြုခြင်းသည် မနှစ်မြို့ဖွယ်အကျိုးသက်ရောက်မှုကို သတိပြုနိုင်သည်။
ဒီမှာ ပုံနှစ်ပုံရှိတယ်။ အခုကျွန်တော်ရှင်းပြပါ့မယ်။ ဤအရာများသည် အချိန်နှင့်ဆက်စပ်နေသော ဂရပ်နှစ်ခုဖြစ်သည်။ ပထမဂရပ်သည် disk အသုံးချမှုဖြစ်သည်။ ဒီအချိန်မှာ 90% နီးပါးလောက် ရောက်နေပါပြီ။ အကယ်၍ သင့်တွင် ရုပ်ပိုင်းဆိုင်ရာဒစ်များဖြင့် ဒေတာဘေ့စ်ချို့ယွင်းမှုရှိပါက RAID ထိန်းချုပ်ကိရိယာအသုံးပြုမှု 90% ဖြင့် ယင်းသည် သတင်းဆိုးဖြစ်သည်။ ဆိုလိုသည်မှာ အနည်းငယ်ပို၍ 100 သို့ရောက်ရှိပြီး I/O ရပ်တန့်သွားမည်ဖြစ်သည်။
သင့်တွင် disk array ရှိပါက၊ ၎င်းသည် အနည်းငယ်ကွဲပြားသော ဇာတ်လမ်းတစ်ခုဖြစ်သည်။ ၎င်းကိုမည်ကဲ့သို့ configured ထားသနည်း၊ ၎င်းသည်မည်သည့် array အမျိုးအစားဖြစ်သည်စသည်တို့အပေါ် မူတည်သည်။
တဆက်တည်းတွင်၊ အတွင်းပိုင်း postgres မြင်ကွင်းမှ ဂရပ်တစ်ခုကို ဤနေရာတွင် စီစဉ်သတ်မှတ်ထားပြီး စစ်ဆေးရေးဂိတ်သည် မည်သို့ဖြစ်ပျက်သည်ကို ပြောပြသည်။ ဤနေရာတွင် အစိမ်းရင့်ရောင်သည် ထပ်တူပြုခြင်းအတွက် အဆိုပါစစ်ဆေးရေးဂိတ်သို့ ထိုအချိန်တွင် buffers မည်မျှရှိနေသည်၊ ဤညစ်ညမ်းသောစာမျက်နှာများကို ပြသသည်။ ဤနေရာတွင် သင်သိထားရမည့် အဓိကအချက်ဖြစ်သည်။ ကျွန်ုပ်တို့တွင် စာမျက်နှာများစွာရှိသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပြီး တစ်ချိန်ချိန်၌ ကျွန်ုပ်တို့သည် ဘုတ်အဖွဲ့ကိုဝင်တိုက်ကြသည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့ရေးလိုက်သည်နှင့် ဤနေရာတွင် disk စနစ်သည် အလွန်အလုပ်များနေပါသည်။ ကျွန်ုပ်တို့၏ စစ်ဆေးရေးဂိတ်သည် ဒစ်ပေါ်တွင် အလွန်ပြင်းထန်သော သက်ရောက်မှုရှိသည်။ အကောင်းဆုံးကတော့၊ အခြေအနေက ဒီထက် ပိုကြည့်သင့်တယ်၊ ဥပမာ၊ ဒီမှာ မှတ်တမ်းတင်မှု နည်းတယ်။ ၎င်းသည် ဤအတိုင်းဆက်လက်ရှိနေစေရန် ဆက်တင်များဖြင့် ကျွန်ုပ်တို့ ၎င်းကို ပြုပြင်နိုင်သည်။ ဆိုလိုသည်မှာ၊ ပြန်လည်အသုံးပြုခြင်းမှာ သေးငယ်သော်လည်း တစ်နေရာရာတွင် ကျွန်ုပ်တို့ ဤနေရာတွင် တစ်ခုခုရေးနေပါသည်။
ဒီပြဿနာကို ကျော်လွှားဖို့ ဘာတွေလုပ်ဆောင်ဖို့ လိုအပ်လဲ။ အကယ်၍ သင်သည် ဒေတာဘေ့စ်အောက်တွင် IO ကို ရပ်တန့်ထားပါက၊ ၎င်းသည် ၎င်းတို့၏ တောင်းဆိုချက်များကို ဖြည့်ဆည်းရန် ရောက်လာသော အသုံးပြုသူအားလုံး စောင့်ဆိုင်းရမည်ဟု ဆိုလိုသည်။
Linux ၏ရှုထောင့်မှကြည့်လျှင် သင်သည် ဟာ့ဒ်ဝဲကောင်းကိုယူကာ မှန်ကန်စွာပြင်ဆင်သတ်မှတ်ထားပါက၊ ဤစစ်ဆေးရေးဂိတ်များကို မကြာခဏလျော့နည်းစေကာ ၎င်းတို့အချင်းချင်းကြား အချိန်ကြာလာသည်နှင့်အမျှ ၎င်းတို့ကို ဖြန့်ကျက်သွားစေရန် ပုံမှန်အားဖြင့် PostgreSQL ကို ပုံမှန်အားဖြင့် configure ပြုလုပ်ပေးကာ၊ ထို့နောက် သင်သည် မူရင်း Debian ဘောင်များထဲသို့ ဝင်ရောက်သွားမည်ဖြစ်သည်။ Linux ဖြန့်ဝေမှုအများစုအတွက်၊ ဤသည်မှာ ပုံဖြစ်သည်- vm.dirty_ratio=20၊ vm.dirty_background_ratio=10။
ဘာကိုဆိုလိုတာလဲ? kernel 2.6 မှ flushing demon တစ်ကောင်ပေါ်လာသည်။ Pdglush သည် ညစ်ပတ်သောစာမျက်နှာများကို kernel ကြားခံမှ နောက်ခံစွန့်ပစ်ခြင်းနှင့် ညစ်ပတ်သောစာမျက်နှာများကို စွန့်ပစ်ရန် လိုအပ်သည့်အခါတွင် စွန့်ပစ်ခြင်းတွင် ပါဝင်နေသည့်အရာအပေါ် မူတည်ပြီး နောက်ကွယ်မှ စွန့်ပစ်ခြင်းသည် အကူအညီမဖြစ်ပါ။
နောက်ခံက ဘယ်အချိန်လာတာလဲ။ ဆာဗာတွင်ရရှိနိုင်သည့် စုစုပေါင်း RAM ၏ 10% ကို kernel ကြားခံရှိ ညစ်ပတ်သောစာမျက်နှာများက သိမ်းပိုက်သောအခါ၊ အထူးရေးထုတ်သည့်လုပ်ဆောင်ချက်ကို နောက်ခံတွင် ခေါ်သည်။ ဘာကြောင့် နောက်ခံဖြစ်တာလဲ။ ကန့်သတ်ချက်တစ်ခုအနေဖြင့် ၎င်းသည် စာမျက်နှာမည်မျှကို ရေးရန် ထည့်သွင်းစဉ်းစားသည်။ ပြီးတော့ သူက N စာမျက်နှာတွေကို ရေးတယ်ဆိုပါစို့။ ဤအရာသည် ခဏတာ အိပ်ပျော်သွားလေသည်။ ထို့နောက် သူမသည် တစ်ဖန်ပြန်လာပြီး စာမျက်နှာအချို့ကို ကူးယူသည်။
ဤသည်မှာ အလွန်ရိုးရှင်းသော ဇာတ်လမ်းဖြစ်သည်။ ဒီနေရာမှာ ပြဿနာက ပိုက်တစ်ခုထဲကို လောင်းထည့်လိုက်တဲ့အခါ ရေကူးကန်နဲ့တူတယ်။ ကျွန်ုပ်တို့၏စစ်ဆေးရေးဂိတ်သို့ရောက်ရှိလာပြီး စွန့်ပစ်ရန် ညစ်ပတ်သောစာမျက်နှာအနည်းငယ်ကို ပေးပို့ပါက၊ ထို့နောက်တွင် အရာအားလုံးကို kernel ကြားခံ pgflush မှ သပ်ရပ်စွာဖြေရှင်းသွားမည်ဖြစ်ပါသည်။
ဤညစ်ညမ်းသောစာမျက်နှာများဆက်လက်စုပုံနေပါက၊ ၎င်းတို့သည် 20% အထိစုပုံနေပြီး၊ ထို့နောက်တွင် OS ၏ဦးစားပေးသည်အရာအားလုံးကို disk သို့ရေးချရန်ဖြစ်သည်၊ ပါဝါပျက်သွားပြီးအရာအားလုံးသည်ကျွန်ုပ်တို့အတွက်ဆိုးရွားလိမ့်မည်။ ဥပမာ၊ ဤဒေတာကို ကျွန်ုပ်တို့ ဆုံးရှုံးပါမည်။
လှည့်ကွက်ကဘာလဲ။ လှည့်ကွက်မှာ ခေတ်သစ်ကမ္ဘာရှိ ဤကန့်သတ်ချက်များသည် စက်တွင်ရှိသော စုစုပေါင်း RAM ၏ 20 နှင့် 10% ဖြစ်သည်၊ ၎င်းတို့သည် သင့်တွင်ရှိသော မည်သည့် disk စနစ်၏ ဖြတ်သန်းမှုနှင့်ပတ်သက်၍ လုံးဝကို ဆိုးရွားလှပါသည်။
သင့်တွင် 128 GB RAM ရှိသည်ဟု မြင်ယောင်ကြည့်ပါ။ 12,8 GB သည် သင့်ဒစ်ခ်စနစ်သို့ ရောက်ရှိသည်။ သင့်တွင် မည်သည့် cache ရှိပါစေ၊ သင့်တွင် မည်သည့် array ရှိပါစေ၊ ၎င်းတို့သည် ဤမျှကြာကြာခံမည်မဟုတ်ပါ။
ထို့ကြောင့်၊ သင်၏ RAID ထိန်းချုပ်ကိရိယာ၏ စွမ်းဆောင်ရည်များအပေါ် အခြေခံ၍ ဤနံပါတ်များကို ချက်ချင်းချိန်ညှိရန် ကျွန်ုပ်တို့ အကြံပြုအပ်ပါသည်။ ကက်ရှ် 512 MB ရှိသော ထိန်းချုပ်ကိရိယာအတွက် ဤနေရာတွင် ကျွန်ုပ်ချက်ချင်း အကြံပြုချက်တစ်ခု ပြုလုပ်ခဲ့သည်။
အရာအားလုံးသည်အလွန်ရိုးရှင်းသည်ဟုယူဆသည်။ သင်သည် vm.dirty_background ကို bytes တွင်ထည့်နိုင်သည်။ ပြီးတော့ ဒီဆက်တင်တွေက အရင်နှစ်ခုကို ပယ်ဖျက်တယ်။ အချိုးနှစ်ခုစလုံးသည် ပုံသေအားဖြင့်ဖြစ်သည် သို့မဟုတ် ဘိုက်ရှိသည့်အရာများကို အသက်သွင်းလိုက်သည်၊ ထို့နောက် bytes ရှိသည့်အရာများသည် အလုပ်လုပ်မည်ဖြစ်သည်။ ဒါပေမယ့် ကျွန်တော်ဟာ DBA အတိုင်ပင်ခံတစ်ယောက်ဖြစ်ပြီး မတူညီတဲ့ client တွေနဲ့ အလုပ်လုပ်တဲ့အတွက်၊ ကျွန်တော် ကောက်ရိုးတွေကို ဆွဲဖို့ကြိုးစားပြီး ဘိုက်နဲ့ဆိုရင်တော့ bytes ပါ။ စီမံခန့်ခွဲသူကောင်းတစ်ဦးသည် ဆာဗာသို့ မန်မိုရီထပ်မံမထည့်ဘဲ၊ ၎င်းကို ပြန်လည်စတင်မည်ဖြစ်ပြီး ပုံသည် တူညီနေမည်ဟု မည်သူမျှ အာမခံချက်မပေးပေ။ အားလုံး အာမခံချက်နဲ့ လိုက်ဖက်အောင် ဒီဂဏန်းတွေကို တွက်ချက်လိုက်ပါ။
အဆင်မပြေရင် ဘာဖြစ်မလဲ။ ပွတ်ဆွဲခြင်းမှန်သမျှကို ထိထိရောက်ရောက် ရပ်တန့်သွားအောင် ရေးခဲ့ဖူးပေမယ့် တကယ်တော့ ဒါက စကားပုံတစ်ခုပါ။ လည်ပတ်မှုစနစ်တွင် ပြဿနာကြီးတစ်ခု ရှိသည် - ၎င်းတွင် ညစ်ပတ်သော စာမျက်နှာများစွာ ပါရှိသောကြောင့် သင့်ဖောက်သည်များ ထုတ်ပေးသည့် IO သည် ထိထိရောက်ရောက် ရပ်တန့်သွားသည်၊ ဆိုလိုသည်မှာ အပလီကေးရှင်းသည် ဒေတာဘေ့စ်သို့ sql query တစ်ခုပေးပို့ရန် ရောက်ရှိလာပြီး စောင့်ဆိုင်းနေပါသည်။ ဒေတာဘေ့စ်ကို စစ်ဆေးရေးဂိတ်တစ်ခုက သိမ်းပိုက်ထားသောကြောင့် ၎င်းအတွက် မည်သည့်အဝင်/အထွက်ကိုမဆို အနိမ့်ဆုံးဦးစားပေးဖြစ်သည်။ မည်သည့်အချိန်တွင် ပြီးဆုံးမည်ကိုမူ လုံးဝမသိရသေးပေ။ နောက်ခံမဟုတ်သော flushing ကိုသင်အောင်မြင်ပြီးသောအခါ၊ သင်၏ IO အားလုံးကို၎င်းကသိမ်းပိုက်သည်ဟုဆိုလိုသည်။ ပြီးသည်တိုင်အောင် သင်သည် ဘာမှလုပ်မည်မဟုတ်။
ဤအစီရင်ခံစာ၏ ဘောင်ကျော်လွန်၍ အရေးကြီးသော အချက်နှစ်ချက် ရှိပါသည်။ ဤဆက်တင်များသည် postgresql.conf ရှိ ဆက်တင်များ၊ ဆိုလိုသည်မှာ စစ်ဆေးရေးဂိတ်ဆက်တင်များနှင့် ကိုက်ညီသင့်သည်။ သင်၏ဒစ်ခ်စနစ်အား လုံလောက်စွာပြင်ဆင်သတ်မှတ်ရပါမည်။ သင့်တွင် RAID တွင် ကက်ရှ်တစ်ခုရှိနေပါက ၎င်းတွင် ဘက်ထရီတစ်လုံးရှိရပါမည်။ လူတွေက ဘက်ထရီမပါဘဲ ကောင်းမွန်တဲ့ cache နဲ့ RAID ကို ဝယ်ကြပါတယ်။ RAID တွင် SSDs များရှိပါက ၎င်းတို့သည် ဆာဗာများဖြစ်ရမည်၊ ထိုနေရာတွင် capacitors ရှိရပါမည်။ ဤတွင်အသေးစိတ်စစ်ဆေးရန်စာရင်းဖြစ်ပါသည်။ ဤလင့်ခ်တွင် PostgreSQL တွင် စွမ်းဆောင်ရည်ဒစ်ကို ဘယ်လိုပြင်ဆင်ရမည်ကို ကျွန်ုပ်၏အစီရင်ခံစာပါရှိသည်။ အဲဒီ့မှာ စစ်ဆေးစရာစာရင်းတွေ ရှိတယ်။
တခြားဘာက ဘဝကို အရမ်းခက်ခဲစေနိုင်လဲ။ ဤအရာများသည် ကန့်သတ်ချက်နှစ်ခုဖြစ်သည်။ သူတို့က အတော်လေးသစ်တယ်။ မူရင်းအားဖြင့်၊ ၎င်းတို့ကို မတူညီသော အပလီကေးရှင်းများတွင် ထည့်သွင်းနိုင်သည်။ လွဲမှားစွာဖွင့်ထားလျှင် ၎င်းတို့သည် ဘဝကို ခက်ခဲစေနိုင်သည်။
အတော်လေး အသစ်အဆန်း နှစ်ချက်ရှိပါတယ်။ ၎င်းတို့သည် တတိယ cores တွင်ပေါ်လာပြီးဖြစ်သည်။ ၎င်းသည် sched_migration_cost မှာ nanoseconds နှင့် sched_autogroup_enabled ဖြစ်ပြီး၊ ၎င်းသည် မူရင်းအတိုင်း တစ်ခုဖြစ်သည်။
ပြီးတော့ သူတို့က မင်းရဲ့ဘဝကို ဘယ်လိုဖျက်ဆီးကြတာလဲ။ sched_migration_cost ဆိုတာဘာလဲ။ Linux တွင်၊ အစီအစဉ်ဆွဲသူသည် လုပ်ငန်းစဉ်တစ်ခုကို CPU တစ်ခုမှ အခြားတစ်ခုသို့ ရွှေ့ပြောင်းနိုင်သည်။ စုံစမ်းမေးမြန်းမှုများကို လုပ်ဆောင်သည့် PostgreSQL အတွက်၊ အခြား CPU သို့ ပြောင်းရွှေ့ခြင်းမှာ လုံးဝရှင်းလင်းမှုမရှိပါ။ လည်ပတ်မှုစနစ်အမြင်အရ၊ သင်သည် openoffice နှင့် terminal အကြား windows ကိုပြောင်းသောအခါ၊ ၎င်းသည် ကောင်းမွန်သော်လည်း၊ ဒေတာဘေ့စ်တစ်ခုအတွက် ဒါက အရမ်းဆိုးတယ်။ ထို့ကြောင့်၊ ကျိုးကြောင်းဆီလျော်သောမူဝါဒသည် အနည်းဆုံး ထောင်ပေါင်းများစွာသော နာနိုစက္ကန့်များစွာကို ကြီးမားသောတန်ဖိုးအဖြစ် သတ်မှတ်ရန်ဖြစ်သည်။
အစီအစဉ်ဆွဲသူအတွက် ဒါက ဘာကိုဆိုလိုပါသလဲ။ ဒီအတောအတွင်း လုပ်ငန်းစဉ်က ပူနေသေးတယ်လို့ ယူဆပါလိမ့်မယ်။ ဆိုလိုသည်မှာ၊ သင်သည် တစ်ခုခုကို အချိန်အတော်ကြာ လုပ်ဆောင်နေသည့် ကာလရှည်ကြာ လည်ပတ်နေသည့် အရောင်းအ၀ယ်တစ်ခုရှိပါက၊ အစီအစဉ်ဆွဲသူသည် ၎င်းကို နားလည်မည်ဖြစ်သည်။ ဤအချိန်ကုန်သွားသည်အထိ ဤလုပ်ငန်းစဉ်ကို မည်သည့်နေရာတွင်မျှ ရွှေ့ပြောင်းရန်မလိုအပ်ဟု သူယူဆလိမ့်မည်။ လုပ်ငန်းစဉ်သည် တစ်ချိန်တည်းတွင် တစ်ခုခုလုပ်ဆောင်ပါက၊ ၎င်းသည် မည်သည့်နေရာတွင်မှ ပြောင်းရွှေ့မည်မဟုတ်ပါ၊ ၎င်းအား ခွဲဝေချထားပေးသော CPU တွင် တိတ်တဆိတ်အလုပ်လုပ်မည်ဖြစ်သည်။ ပြီးတော့ ရလဒ်က အရမ်းကောင်းတယ်။
ဒုတိယအချက်မှာ autogroup ဖြစ်သည်။ ခေတ်မီဒေတာဘေ့စ်များနှင့်မသက်ဆိုင်သည့် သီးခြားအလုပ်များများအတွက် အကြံကောင်းတစ်ခုရှိသည် - ၎င်းသည် ၎င်းတို့စတင်သည့် virtual terminal မှ လုပ်ငန်းစဉ်များကို အုပ်စုဖွဲ့ရန်ဖြစ်သည်။ ဒါက တချို့အလုပ်တွေအတွက် အဆင်ပြေတယ်။ လက်တွေ့တွင်၊ PostgreSQL သည် terminal တစ်ခုမှအလုပ်လုပ်သော prefork ပါရှိသော multi-process စနစ်တစ်ခုဖြစ်သည်။ သင့်တွင်သော့ခတ်ထားသောစာရေးဆရာ၊ စစ်ဆေးရေးဂိတ်တစ်ခုရှိပြီး သင့်ဖောက်သည်တောင်းဆိုမှုများအားလုံးကို CPU တစ်ခုစီအလိုက် အချိန်ဇယားတစ်ခုအဖြစ် အုပ်စုဖွဲ့မည်ဖြစ်သည်။ တယောက်နဲ့တယောက် အနှောင့်အယှက်ပေးပြီး သူ့ကို ကြာကြာသိမ်းပိုက်ထားနိုင်ဖို့ သူလွတ်မြောက်ဖို့ တညီတညွတ်တည်း စောင့်နေကြလိမ့်မယ်။ ဤကဲ့သို့ ဝန်ထုပ်ဝန်ပိုးကိစ္စတွင် လုံးဝမလိုအပ်သော ဇာတ်လမ်းဖြစ်သောကြောင့် ပိတ်ရန် လိုအပ်ပါသည်။
ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက် Alexey Lesovsky သည် ရိုးရှင်းသော pgbench ဖြင့် စမ်းသပ်မှုများပြုလုပ်ခဲ့ပြီး၊ ၎င်းသည် ပမာဏအစဉ်လိုက်ဖြင့် migration_cost ကိုတိုးမြှင့်ကာ autogroup ကိုပိတ်ခဲ့သည်။ မကောင်းတဲ့ဟာ့ဒ်ဝဲရဲ့ ခြားနားချက်က 10% နီးပါးရှိပါတယ်။. လူများက မေးမြန်းမှုအမြန်နှုန်းအတွက် အလားတူပြောင်းလဲမှုများ၏ရလဒ်များကိုပေးသည့် postgres စာပို့စာရင်းတွင် ဆွေးနွေးမှုတစ်ခုရှိသည်။ 50% လွှမ်းမိုးသည်. အဲဒီလို ဇာတ်လမ်းတွေ တော်တော်များတယ်။
နောက်ဆုံးအနေနဲ့ ပါဝါချွေတာရေးမူဝါဒအကြောင်း။ ကောင်းသောအချက်မှာ Linux ကိုယခုလက်ပ်တော့ပေါ်တွင်အသုံးပြုနိုင်သည်။ ပြီးတော့ ဘထ္ထရီကို ကောင်းကောင်းအသုံးခံပါလိမ့်မယ်။ ဒါပေမယ့် ရုတ်တရက် ဆာဗာပေါ်မှာလည်း ဒီလိုဖြစ်သွားနိုင်တယ်ဆိုတာ ပေါ်လာပါတယ်။
ထို့အပြင်၊ အကယ်၍ သင်သည် အချို့သော hoster များမှ ဆာဗာများကို ငှားရမ်းပါက၊ "ကောင်းသော" hosters များသည် သင့်တွင် ပိုမိုကောင်းမွန်သောစွမ်းဆောင်ရည်ရှိကြောင်း ဂရုမစိုက်ပါ။ ၎င်းတို့၏တာဝန်မှာ သံဓာတ်ကို တတ်နိုင်သမျှ ထိရောက်စွာ အသုံးချနိုင်စေရန်ဖြစ်သည်။ ထို့ကြောင့်၊ ပုံမှန်အားဖြင့် ၎င်းတို့သည် လည်ပတ်မှုစနစ်တွင် လက်ပ်တော့ပါဝါချွေတာရေးမုဒ်ကို ဖွင့်နိုင်သည်။
ဝန်လေးသော ဒေတာဘေ့စ်ပါသော ဆာဗာတွင် ဤအရာများကို သင်အသုံးပြုပါက၊ သင်၏ရွေးချယ်မှုသည် acpi_cpufreq + permormance ဖြစ်သည်။ ondemand မှာတောင် ပြဿနာရှိမယ်။
Intel_pstate သည် အနည်းငယ်ကွဲပြားသော ဒရိုက်ဘာတစ်ခုဖြစ်သည်။ အခုနောက်ပိုင်းမှာ ပိုကောင်းလာတာနဲ့အမျှ ဒီတစ်ခုကို ဦးစားပေးလာပါပြီ။
ထို့ကြောင့် အုပ်ချုပ်ရေးမှူးသည် စွမ်းဆောင်ရည်သာဖြစ်သည်။ Ondemand၊ powersave နှင့် အခြားအရာအားလုံးသည် သင့်အတွက်မဟုတ်ပေ။
သင် powersave ကိုဖွင့်ထားလျှင် PostgreSQL ခွဲခြမ်းစိတ်ဖြာခြင်း၏ရလဒ်များသည် လက်တွေ့အားဖြင့် သင့်ဒေတာဘေ့စ်အောက်ရှိ CPU သည် လုံးဝခန့်မှန်းမရနိုင်သောနည်းလမ်းဖြင့် လုပ်ဆောင်နေသောကြောင့်ဖြစ်သည်။
ဤအရာများကို မူရင်းအတိုင်း ထည့်သွင်းနိုင်ပါသည်။ ၎င်းတို့ကို မူရင်းအတိုင်း ဖွင့်ထားခြင်းရှိမရှိ သေချာကြည့်ရှုပါ။ ဒါက တကယ့်ပြဿနာကြီးတစ်ခု ဖြစ်နိုင်တယ်။
နောက်ဆုံးအနေနဲ့၊ ဒီကိစ္စကို နေ့တိုင်း ဦးတည်လုပ်ဆောင်နေတဲ့ Max Boguk နဲ့ Alexey Lesovsky တို့ရဲ့ PosgreSQL-Consulting DBA အဖွဲ့မှ အမျိုးသားတွေကို ကျေးဇူးတင်ကြောင်း ပြောချင်ပါတယ်။ ပြီးတော့ ကျွန်တော်တို့ ဖောက်သည်တွေအတွက် တတ်နိုင်သမျှ အကောင်းဆုံးဖြစ်အောင် ကြိုးစားပြီး အားလုံးက သူတို့အတွက် အဆင်ပြေပါတယ်။ ၎င်းသည် လေကြောင်းဘေးကင်းရေး လမ်းညွှန်ချက်နှင့် တူသည်။ ဤနေရာတွင် အရာအားလုံးကို သွေးဖြင့်ရေးထားသည်။ ဤအခွံမာသီးအသီးအသီးကိုအချို့သောပြဿနာများ၏လုပ်ငန်းစဉ်များတွင်တွေ့ရှိနိုင်ပါသည်။ မင်းနဲ့သူတို့ကို မျှဝေရတာ ငါပျော်တယ်။
မေးခွန်းများကို:
ကျေးဇူးတင်ပါသည်! ဥပမာအားဖြင့်၊ ကုမ္ပဏီတစ်ခုသည် ငွေစုလိုပြီး ဆာဗာတစ်ခုတွင် ဒေတာဘေ့စ်နှင့် အပလီကေးရှင်းယုတ္တိကို ထားရှိလိုလျှင် သို့မဟုတ် PostgreSQL ကွန်တိန်နာတွင် အလုပ်လုပ်သည့် ကုမ္ပဏီသည် ခေတ်မီသော Microservice Architectures ၏ ခေတ်ရေစီးကြောင်းအတိုင်း လိုက်နာပါက၊ လှည့်ကွက်ကဘာလဲ။ Sysctl သည် တစ်ကမ္ဘာလုံးရှိ kernel တစ်ခုလုံးအပေါ် သက်ရောက်မှုရှိမည်ဖြစ်သည်။ sysctls သည် ကွန်တိန်နာတစ်ခုပေါ်တွင် သီးခြားစီလုပ်ဆောင်နိုင်ရန် တစ်နည်းနည်းဖြင့် အတုပြုလုပ်ထားကြောင်း ကျွန်ုပ်မကြားမိပါ။ cgroup တစ်ခုသာရှိပြီး ထိုနေရာတွင် ထိန်းချုပ်မှု၏ အစိတ်အပိုင်းတစ်ခုသာရှိသည်။ ဒါကို မင်းဘယ်လိုနေနိုင်မလဲ။ သို့မဟုတ် သင်သည် စွမ်းဆောင်ရည်ကို လိုချင်ပါက၊ သီးခြား ဟာ့ဒ်ဝဲဆာဗာတွင် PostgreSQL ကိုဖွင့်ပြီး ၎င်းကို ချိန်ညှိပါ။
ကျွန်ုပ်တို့သည် သင့်မေးခွန်းကို နည်းလမ်းသုံးသွယ်ဖြင့် ဖြေကြားခဲ့ပါသည်။ ချိန်ညှိနိုင်သော ဟာ့ဒ်ဝဲဆာဗာ စသည်တို့ကို ကျွန်ုပ်တို့ပြောနေခြင်းမဟုတ်ပါက၊ အေးအေးလူလူ ဤဆက်တင်များမပါဘဲ အရာအားလုံး အဆင်ပြေသွားပါမည်။ အကယ်၍ သင့်တွင် ဤဆက်တင်များပြုလုပ်ရန် လိုအပ်သည့် ဝန်ရှိနေပါက၊ သင်သည် ဤဆက်တင်များထက် စောပြီး သံဆာဗာသို့ ရောက်ရှိလာမည်ဖြစ်သည်။
ပြသနာကဘာလဲ? ၎င်းသည် virtual machine ဖြစ်ပါက၊ ဥပမာအားဖြင့်၊ virtual machines အများစုတွင် disk ၏ latency သည် အတော်လေး ကွဲလွဲနေသဖြင့် ပြဿနာများစွာကို ကြုံတွေ့ရနိုင်ချေများပါသည်။ disk ဖြတ်သန်းစီးဆင်းမှု ကောင်းမွန်သော်လည်း၊ စစ်ဆေးရေးဂိတ်တွင် ဖြစ်ပျက်ခဲ့သည့် ပျမ်းမျှဖြတ်သန်းမှုအား ကြီးကြီးမားမား မထိခိုက်စေသော I/O လွှဲပြောင်းမှု မအောင်မြင်ပါက စစ်ဆေးရေးဂိတ်တွင် သို့မဟုတ် WAL သို့ စာရေးနေချိန်၊ ထို့နောက် ဒေတာဘေ့စ်သည် ၎င်းအတွက် များစွာ နစ်နာမည်ဖြစ်သည်။ ပြီးတော့ ဒီပြဿနာတွေကို သင်မပြေးခင် ဒါကို သတိထားမိပါလိမ့်မယ်။
တူညီသောဆာဗာတွင် NGINX ရှိပါက၊ သင်သည်လည်း အလားတူပြဿနာရှိလိမ့်မည်။ မျှဝေမှတ်ဉာဏ်အတွက် တိုက်ပွဲဝင်မည်။ ပြီးတော့ ဒီမှာဖော်ပြထားတဲ့ ပြဿနာတွေကို သင်ရောက်သွားမှာ မဟုတ်ပါဘူး။
သို့သော် အခြားတစ်ဖက်တွင်၊ ဤသတ်မှတ်ချက်အချို့သည် သင့်အတွက် ဆက်နွယ်နေဦးမည်ဖြစ်သည်။ ဥပမာအားဖြင့်၊ sysctl ဖြင့်ညစ်ပတ်သောအချိုးအစားကိုသတ်မှတ်ပါ - မည်သို့ပင်ဆိုစေ၊ ၎င်းသည်ကူညီလိမ့်မည်။ တစ်နည်းမဟုတ်တစ်နည်း၊ သင်သည် disk နှင့်အပြန်အလှန်အကျိုးသက်ရောက်မှုရှိလိမ့်မည်။ မှားယွင်းသောပုံစံအတိုင်းဖြစ်လိမ့်မည်။ ၎င်းသည် ကျွန်ုပ်ပြသခဲ့သည့် ဘောင်များအတွက် ယေဘုယျအားဖြင့် ပုံသေဖြစ်သည်။ မည်သို့ပင်ဆိုစေကာမူ ၎င်းတို့ကို ပြောင်းလဲခြင်းသည် ပိုကောင်းပါသည်။
သို့သော် NUMA တွင် ပြဿနာများရှိနိုင်သည်။ ဥပမာ၊ VmWare သည် အတိအကျဆန့်ကျင်ဘက်ဆက်တင်များဖြင့် NUMA နှင့် ကောင်းမွန်စွာအလုပ်လုပ်သည်။ ဤနေရာတွင် သင်သည် သံဆာဗာ သို့မဟုတ် သံမဟုတ်သောတစ်ခုကို ရွေးချယ်ရမည်ဖြစ်သည်။
Amazon AWS နှင့် ပတ်သက်သော မေးခွန်းတစ်ခုရှိသည်။ ၎င်းတို့တွင် ကြိုတင်ပြင်ဆင်ထားသော ပုံများရှိသည်။ ၎င်းတို့ထဲမှ တစ်ခုကို Amazon RDS ဟုခေါ်သည်။ ၎င်းတို့၏လည်ပတ်မှုစနစ်အတွက် စိတ်ကြိုက်ဆက်တင်များ ရှိပါသလား။
အဲဒီမှာ ဆက်တင်တွေရှိတယ်၊ ဒါပေမယ့် အဲဒါတွေက ကွဲပြားတဲ့ ဆက်တင်တွေ။ ဤနေရာတွင် ဒေတာဘေ့စ်က ဤအရာကို မည်သို့အသုံးပြုမည်ကို သတ်မှတ်ချက်ဖြင့် ကျွန်ုပ်တို့သည် လည်ပတ်မှုစနစ်အား ပြင်ဆင်သတ်မှတ်ပါသည်။ ပုံသဏ္ဍာန်ကဲ့သို့သော ယခု ကျွန်ုပ်တို့ဘယ်ကိုသွားသင့်သည်ကို ဆုံးဖြတ်ပေးသည့် ဘောင်များရှိပါသည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် ဤမျှလောက်များစွာသော အရင်းအမြစ်များ လိုအပ်သည်၊ ယခု ၎င်းတို့ကို စားသုံးပါမည်။ ယင်းနောက်တွင်၊ Amazon RDS သည် ဤအရင်းအမြစ်များကို တင်းကျပ်စေပြီး စွမ်းဆောင်ရည်ကျဆင်းသွားပါသည်။ ဒီကိစ္စနဲ့ ပတ်သက်ပြီး လူတွေ ဘယ်လို စပြီး ရှုပ်နေကြလဲ ဆိုတဲ့ ဇာတ်လမ်းတွေ ရှိတယ်။ တခါတရံမှာတောင် တော်တော်အောင်မြင်တယ်။ ဒါပေမယ့် ဒါက OS ဆက်တင်တွေနဲ့ ဘာမှမဆိုင်ပါဘူး။ Cloud ကို Hack တာနဲ့တူတယ်။ အဲဒါ မတူဘူး။
ကြီးမားသော TLB နှင့် နှိုင်းယှဉ်လျှင် ကြီးမားသော ဖောက်ထွင်းမြင်ရသော စာမျက်နှာများသည် အဘယ်ကြောင့် အကျိုးသက်ရောက်မှု မရှိသနည်း။
မပေးနဲ့။ ဒါကို ပုံစံအမျိုးမျိုးနဲ့ ရှင်းပြနိုင်ပါတယ်။ ဒါပေမယ့် တကယ်တော့ သူတို့က မပေးဘူး။ PostgreSQL ၏သမိုင်းကဘာလဲ။ စတင်ချိန်တွင်၊ ၎င်းသည် မျှဝေထားသော မှတ်ဉာဏ်၏ ကြီးမားသောအပိုင်းကို ခွဲဝေပေးသည်။ ပွင့်လင်းမြင်သာမှု ရှိ၊ မရှိသည် လုံးဝမသက်ဆိုင်ပါ။ အစမှာ သူတို့ ပေါ်လွင်နေတယ်ဆိုတဲ့အချက်က အရာအားလုံးကို ရှင်းပြပါတယ်။ မန်မိုရီအများကြီးရှိ၍ shared_memory အပိုင်းကို ပြန်လည်တည်ဆောက်ရန် လိုအပ်ပါက၊ Transparent ကြီးမားသော စာမျက်နှာများသည် သက်ဆိုင်ရာဖြစ်လိမ့်မည်။ PostgreSQL တွင်၊ ၎င်းကို အစပိုင်းတွင် ကြီးမားသောအတုံးတစ်ခုဖြင့် ခွဲဝေပေးထားပြီး၊ ထို့နောက်တွင် မည်သည့်အရာမျှ ထူးခြားမလာပါ။ သင်သည် ၎င်းကို သုံးနိုင်သည်၊ သို့သော် တစ်စုံတစ်ရာကို ပြန်လည်ခွဲဝေပေးသည့်အခါ shared_memory ၏ အကျင့်ပျက်ခြစားမှုကို ရရှိရန် အခွင့်အလမ်းရှိသည်။ PostgreSQL သည် ဤအကြောင်းကို မသိပါ။
source: www.habr.com