PostgreSQL ကို ချိန်ညှိခြင်းအတွက် စက်မှုဆိုင်ရာချဉ်းကပ်မှု- ဒေတာဘေ့စ်များနှင့် စမ်းသပ်မှုများ။ Nikolay Samokhvalov

Nikolai Samokhvalov ၏ "PostgreSQL ကို ချိန်ညှိရန် စက်မှုချဉ်းကပ်မှု- ဒေတာဘေ့စ်များဆိုင်ရာ စမ်းသပ်မှုများ" ၏ မှတ်တမ်းကို ဖတ်ရန် ကျွန်ုပ်အကြံပြုလိုပါသည်။

Shared_buffers = 25% – အများကြီး ဒါမှမဟုတ် နည်းနည်းပဲလား။ ဒါမှမဟုတ် မှန်သလား။ ဤအကြံပြုချက်သည် သင့်အထူးကိစ္စရပ်တွင် သင့်လျော်မှုရှိ၊

"အရွယ်ရောက်ပြီးသူကဲ့သို့" postgresql.conf parameters များကိုရွေးချယ်ခြင်း၏ပြဿနာကိုချဉ်းကပ်ရန်အချိန်ဖြစ်သည်။ မျက်မမြင် "အော်တိုအသံဖမ်းစက်များ" သို့မဟုတ် ဆောင်းပါးများနှင့် ဘလော့ဂ်များမှ ခေတ်မမီသော အကြံဉာဏ်များ အကူအညီဖြင့် မဟုတ်ဘဲ၊ အခြေခံ၍-

1. ဒေတာဘေ့စ်များပေါ်တွင် တင်းကြပ်စွာ စိစစ်ထားသော စမ်းသပ်မှုများကို အမြောက်အမြားဖြင့် အလိုအလျောက် လုပ်ဆောင်ပြီး ၎င်းတို့ကို “တိုက်ဖျက်ရန်” ဖြစ်နိုင်သမျှ အနီးစပ်ဆုံး အခြေအနေများအောက်တွင်၊
2. DBMS နှင့် OS ၏ အင်္ဂါရပ်များကို နက်နက်နဲနဲ နားလည်သည်။

Nancy CLI ကို အသုံးပြုခြင်း (https://gitlab.com/postgres.ai/nancy) သီးခြားဥပမာ - နာမည်ဆိုးဖြင့်ကျော်ကြားသော shared_buffers - ကွဲပြားခြားနားသောအခြေအနေများတွင်၊ မတူညီသောပရောဂျက်များတွင်ကြည့်ရှုပြီးကျွန်ုပ်တို့၏အခြေခံအဆောက်အအုံ၊ ဒေတာဘေ့စ်နှင့်ဝန်အတွက်အကောင်းဆုံးဆက်တင်ကိုမည်သို့ရွေးချယ်ရမည်ကိုရှာဖွေပါ။

ဒေတာဘေ့စ်များနှင့် စမ်းသပ်မှုများအကြောင်း ဆွေးနွေးပါမည်။ ဒီဇာတ်လမ်းက ခြောက်လကျော်လောက်ကြာတယ်။

ငါ့အကြောင်းနည်းနည်း။ Postgres နှင့် 14 နှစ်ကျော်အတွေ့အကြုံ။ လူမှုကွန်ရက်ကုမ္ပဏီ အများအပြားကို တည်ထောင်ခဲ့သည်။ Postgres ကို နေရာတိုင်းတွင် အသုံးပြုသည်။

Meetup တွင် RuPostgres အဖွဲ့သည် ကမ္ဘာ့ဒုတိယနေရာဖြစ်သည်။ ကျွန်ုပ်တို့သည် လူ ၂၀၀၀ ကို တဖြည်းဖြည်း ချဉ်းကပ်လာသည်။ RuPostgres.org

Highload အပါအဝင် ကွန်ဖရင့်အမျိုးမျိုး၏ PC များတွင်၊ အထူးသဖြင့် Postgres သည် အစကတည်းက ဒေတာဘေ့စ်များအတွက် ကျွန်ုပ်တာဝန်ယူပါသည်။

ပြီးခဲ့သည့်နှစ်အနည်းငယ်အတွင်း၊ ကျွန်ုပ်သည် ကျွန်ုပ်၏ Postgres အတိုင်ပင်ခံအလေ့အကျင့် 11 အချိန်ဇုန်ကို ဤနေရာမှ ပြန်လည်စတင်ခဲ့ပါသည်။

ဒါကို လွန်ခဲ့တဲ့နှစ်အနည်းငယ်က ကျွန်တော်လုပ်တဲ့အခါ၊ 2010 ခုနှစ်ကတည်းက ဖြစ်နိုင်တဲ့ Postgres နဲ့ တက်ကြွတဲ့လက်စွဲအလုပ်မှာ ခဏနားခဲ့တယ်။ DBA ၏ လုပ်ရိုးလုပ်စဉ် အနည်းငယ် ပြောင်းလဲသွားသည်ကို ကျွန်ုပ် အံ့သြမိသည်၊ လက်လုပ်လက်စား မည်မျှ လိုအပ်နေသေးသည်ကို ကျွန်ုပ် အံ့သြမိသည်။ ပြီးတော့ ဒီမှာ တစ်ခုခု မှားနေပြီလို့ ချက်ခြင်း ထင်ခဲ့တယ်၊ အရာအားလုံးကို ပိုအလိုအလျောက် လုပ်ဖို့လိုတယ်။

ဝေးလံခေါင်သီသောအချိန်ဖြစ်သောကြောင့် ဖောက်သည်အများစုသည် တိမ်တိုက်ထဲတွင် ရှိနေကြသည်။ တော်တော်များများက အလိုအလျောက်ဖြစ်နေပြီဆိုတာ သိသာပါတယ်။ ဒီအကြောင်းကို နောက်မှပြောပါ။ ဆိုလိုသည်မှာ၊ ဤအရာအားလုံးသည် ဒေတာဘေ့စ်အများအပြားကို စီမံခန့်ခွဲနိုင်စေရန်အတွက် DBA လုပ်ဆောင်ချက်အားလုံးနီးပါးကို အလိုအလျောက်လုပ်ဆောင်ပေးမည့် ကိရိယာများစွာရှိသင့်သည်ဟု အယူအဆကို ဖြစ်ပေါ်စေခဲ့သည်။

ဤအစီရင်ခံစာတွင် ပါဝင်မည်မဟုတ်ပါ-

• “ငွေကျည်ဆန်များ” နှင့် ကဲ့သို့သော ထုတ်ပြန်ချက်များသည် - 8 GB သို့မဟုတ် 25% shared_buffers ကိုသတ်မှတ်ထားပါက သင်အဆင်ပြေပါလိမ့်မည်။ shared_buffers အကြောင်း အများကြီးရှိမည်မဟုတ်ပါ။
• အသေအကြေ "innards" ။

ဘာဖြစ်မလဲ?

• ကျွန်ုပ်တို့ ကျင့်သုံးပြီး ပြုစုပျိုးထောင်ပေးသော ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ခြင်းဆိုင်ရာ အခြေခံမူများ ရှိပါမည်။ လမ်းတစ်လျှောက်တွင် ပေါ်ပေါက်လာသော စိတ်ကူးစိတ်သန်း အမျိုးမျိုးနှင့် Open Source တွင် အများစုအတွက် ကျွန်ုပ်တို့ ဖန်တီးပေးသော ကိရိယာ အမျိုးမျိုး ရှိလိမ့်မည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် Open Source တွင် အခြေခံ ပြုလုပ်ထားပါသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့တွင် လက်မှတ်များရှိသည်၊ ဆက်သွယ်ရေးအားလုံးသည် လက်တွေ့တွင် Open Source ဖြစ်သည်။ ယခုကျွန်ုပ်တို့ဘာလုပ်နေသည်၊ နောက်ထွက်ရှိမည့်အရာစသည်တို့ကိုသင်မြင်နိုင်သည်။
• ကုမ္ပဏီအများအပြားတွင် ဤအခြေခံမူများ၊ ဤကိရိယာများကို အသုံးပြုရာတွင် အတွေ့အကြုံအချို့ရှိလိမ့်မည်- အသေးစားလုပ်ငန်းစတင်မှုမှသည် ကုမ္ပဏီကြီးများအထိ။

ဒါတွေအားလုံး ဘယ်လိုတိုးတက်နေလဲ။

ပထမဦးစွာ၊ DBA ၏ အဓိကတာဝန်မှာ ဥပမာများဖန်တီးခြင်း၊ အရန်ကူးယူခြင်း စသည်တို့ကို သေချာစေသည့်အပြင်၊ ပိတ်ဆို့မှုများကို ရှာဖွေရန်နှင့် စွမ်းဆောင်ရည်ကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ရန်ဖြစ်သည်။

ယခု ဤကဲ့သို့ တပ်ဆင်ထားပါသည်။ စောင့်ကြည့်စစ်ဆေးတာကို ကြည့်တယ်၊ တစ်ခုခုတော့ တွေ့ပေမယ့် အသေးစိတ်အချက်တချို့တော့ လွဲနေတယ်။ ကျွန်ုပ်တို့သည် ပုံမှန်အားဖြင့် ကျွန်ုပ်တို့၏လက်ဖြင့် ပိုမိုဂရုတစိုက်စတင်တူးဖော်ကြပြီး ၎င်းကို မည်သို့လုပ်ဆောင်ရမည်ကို တစ်နည်းမဟုတ်တစ်နည်း နားလည်ကြသည်။

ပြီးတော့ ချဉ်းကပ်မှု နှစ်ခုရှိတယ်။ Pg_stat_statements သည် နှေးကွေးသော မေးမြန်းမှုများကို ဖော်ထုတ်ရန်အတွက် မူရင်းဖြေရှင်းချက်ဖြစ်သည်။ pgBadger ကို အသုံးပြု၍ Postgres မှတ်တမ်းများကို ခွဲခြမ်းစိတ်ဖြာပါ။

ချဉ်းကပ်မှုတိုင်းတွင် ကြီးမားသော အားနည်းချက်များရှိသည်။ ပထမချဉ်းကပ်မှုတွင်၊ ကျွန်ုပ်တို့သည် parameters အားလုံးကိုဖယ်ရှားခဲ့သည်။ အကယ်၍ ကော်လံသည် "?" နှင့် ညီမျှသည့် SELECT * FROM ဇယားအုပ်စုများကို ကြည့်ပါက၊ သို့မဟုတ် Postgres 10 ကတည်းက "$"။ ၎င်းသည် အညွှန်းစကင်န် သို့မဟုတ် seq စကင်န်ဟုတ်မဟုတ် ကျွန်ုပ်တို့မသိပါ။ ၎င်းသည် parameter ပေါ်တွင်အလွန်မူတည်သည်။ ထိုနေရာတွင် တွေ့ရခဲသောတန်ဖိုးကို အစားထိုးပါက၊ ၎င်းသည် အညွှန်းစကင်န်တစ်ခု ဖြစ်လိမ့်မည်။ အဲဒီမှာ ဇယားရဲ့ 90% ရှိတဲ့တန်ဖိုးကို အစားထိုးရင်၊ Postgres က စာရင်းဇယားတွေကို သိတဲ့အတွက် seq scan က သိသာထင်ရှားလာပါလိမ့်မယ်။ အချို့သောအလုပ်များ လုပ်ဆောင်နေသော်လည်း၊ ၎င်းသည် pg_stat_statements ၏ ကြီးမားသောအားနည်းချက်ဖြစ်သည်။

မှတ်တမ်းခွဲခြမ်းစိတ်ဖြာမှု၏ အကြီးမားဆုံးအားနည်းချက်မှာ စည်းမျဉ်းတစ်ခုအနေဖြင့် "log_min_duration_statement = 0" ကို မတတ်နိုင်ခြင်းကြောင့်ဖြစ်သည်။ ပြီးတော့ ဒီအကြောင်းလည်း ပြောမယ်။ ထို့ကြောင့် ပုံတစ်ခုလုံးကို မမြင်ရပါ။ အချို့သောမေးမြန်းချက်သည် အလွန်လျင်မြန်သောအားဖြင့် အရင်းအမြစ်များစွာကို သုံးစွဲနိုင်သော်လည်း ၎င်းသည် သင့်သတ်မှတ်ချက်ထက် ကျော်လွန်နေသောကြောင့် ၎င်းကို သင်တွေ့မည်မဟုတ်ပါ။

DBA များသည် ၎င်းတို့တွေ့ရှိသည့် ပြဿနာများကို မည်သို့ဖြေရှင်းကြသနည်း။

ဥပမာအားဖြင့်၊ ပြဿနာအချို့ကို ကျွန်ုပ်တို့တွေ့ရှိခဲ့သည်။ အများအားဖြင့် ဘာလုပ်ကြသလဲ။ အကယ်၍ သင်သည် ဆော့ဖ်ဝဲရေးသားသူဖြစ်ပါက၊ သင်သည် အရွယ်အစားတူမဟုတ်သော အချို့သောဥပမာများတွင် တစ်ခုခုကို လုပ်ဆောင်နေလိမ့်မည်။ သင် DBA ဖြစ်ပါက သင့်တွင် ဇာတ်ခုံရှိသည်။ ပြီးတော့ တစ်ခုပဲရှိနိုင်တယ်။ ပြီးတော့ သူက ခြောက်လနောက်ကျသွားတယ်။ ပြီးတော့ ခင်ဗျားက ထုတ်လုပ်မှုကို သွားလိမ့်မယ်လို့ ထင်သလား။ ပြီးတော့ အတွေ့အကြုံရှိတဲ့ DBAs တွေတောင် ထုတ်လုပ်မှုကို စစ်ဆေးပြီး ပုံစံတူလုပ်ပါ။ ၎င်းတို့သည် ယာယီအညွှန်းတစ်ခုကို ဖန်တီးပြီး၊ ၎င်းကို ကူညီပေးကြောင်း၊ ၎င်းကို ချပေးကာ ရွှေ့ပြောင်းမှုဖိုင်များတွင် ထည့်သွင်းနိုင်ရန် ဆော့ဖ်ဝဲရေးသားသူများထံ ပေးဆောင်ရန် သေချာစေပါသည်။ ဒါက အခု ဖြစ်ပျက်နေတဲ့ မိုက်မဲမှုမျိုးပါ။ ပြီးတော့ ဒါက ပြဿနာတစ်ခုပါ။

• ချိန်ညှိဖွဲ့စည်းမှု။
• အညွှန်းအစုံကို အကောင်းဆုံးဖြစ်အောင်လုပ်ပါ။
• SQL query ကို သူ့ဘာသာသူ ပြောင်းပါ (ဒါက အခက်ခဲဆုံးနည်းလမ်း)။
• စွမ်းရည်ထည့်ပါ (ကိစ္စအများစုတွင် အလွယ်ကူဆုံးနည်းလမ်း)။

ဒီအရာတွေ အများကြီး ဆက်ဖြစ်နေပါတယ်။ Postgres တွင် လက်ကိုင်များစွာရှိသည်။ သိစရာတွေအများကြီးရှိတယ်။ Postgres တွင် အညွှန်းများစွာ ရှိပြီး၊ ဤညီလာခံကို စီစဉ်သူများကိုလည်း ကျေးဇူးတင်ပါသည်။ ဤအရာအားလုံးကို သိထားရန် လိုအပ်ပြီး ၎င်းသည် DBA မဟုတ်သူများ DBA များသည် အောက်လမ်းပညာကို လေ့ကျင့်နေသလို ခံစားရစေသည်။ ဆိုလိုသည်မှာ၊ ဤအရာအားလုံးကိုပုံမှန်အတိုင်းနားလည်ရန်သင် ၁၀ နှစ်ကြာလေ့လာရန်လိုအပ်သည်။

ပြီးတော့ ငါက ဒီအနက်ရောင်မှော်ပညာကို ဆန့်ကျင်သူပါ။ နည်းပညာရှိအောင် အားလုံးကို လုပ်ချင်တယ်၊ ဒါတွေအားလုံးမှာ ပင်ကိုယ်က မရှိဘူး။

လက်တွေ့ဘဝဥပမာများ

ကျွန်ုပ်၏ကိုယ်ပိုင် အပါအဝင် အနည်းဆုံး ပရောဂျက်နှစ်ခုတွင် ဤအရာကို ကျွန်ုပ်သတိပြုမိသည်။ default_statistict_target အတွက် 1 တန်ဖိုးသည် ကောင်းမွန်ကြောင်း အခြားဘလော့ဂ်ပို့စ်တစ်ခုက ပြောပြသည်။ အိုကေ၊ ထုတ်လုပ်ရေးမှာ စမ်းကြည့်ရအောင်။

ဤနေရာတွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ tool ကိုအသုံးပြုပြီး နှစ်နှစ်အကြာတွင်၊ ယနေ့ကျွန်ုပ်တို့ပြောနေသောဒေတာဘေ့စ်များပေါ်တွင်စမ်းသပ်မှုများ၏အကူအညီဖြင့်၊ ကျွန်ုပ်တို့သည် အဘယ်အရာနှင့်ဖြစ်လာခဲ့သည်ကို နှိုင်းယှဉ်နိုင်သည်။

အဲဒါအတွက် စမ်းသပ်မှုတစ်ခု ဖန်တီးဖို့ လိုပါတယ်။ ၎င်းတွင် အပိုင်းလေးပိုင်းပါဝင်သည်။

• ပထမအချက်က ပတ်ဝန်းကျင်။ ဟာ့ဒ်ဝဲတစ်ပိုင်းလိုတယ်။ ကုမ္ပဏီတချို့ကိုလာပြီး စာချုပ်ချုပ်တဲ့အခါ၊ ထုတ်လုပ်ရေးနဲ့ တူညီတဲ့ ဟာ့ဒ်ဝဲတွေကို ပေးဖို့ သူတို့ကို ပြောထားတယ်။ မင်းရဲ့မာစတာတစ်ယောက်စီအတွက်၊ ငါဒီလိုဟာ့ဒ်ဝဲတစ်ခု အနည်းဆုံးလိုတယ်။ ဤအရာသည် Amazon သို့မဟုတ် Google ရှိ ဥပမာ virtual machine တစ်ခုဖြစ်သည် သို့မဟုတ် ကျွန်ုပ်သည် အတိအကျတူညီသော ဟာ့ဒ်ဝဲတစ်ခု လိုအပ်ပါသည်။ အဲဒါကတော့ ပတ်ဝန်းကျင်ကို ပြန်ဖန်တီးချင်တယ်။ ပတ်ဝန်းကျင် အယူအဆတွင် ကျွန်ုပ်တို့သည် Postgres ၏ အဓိကဗားရှင်းကို ထည့်သွင်းထားသည်။
• ဒုတိယအပိုင်းသည် ကျွန်ုပ်တို့၏ သုတေသနပြုချက်ဖြစ်သည်။ ဒါက database တစ်ခုပါ။ နည်းလမ်းများစွာဖြင့် ဖန်တီးနိုင်သည်။ ငါ မင်းကို ဘယ်လိုလုပ်ပြမယ်။
• တတိယအပိုင်းကတော့ ဝန်ပေါ့။ ဒါက အခက်ခဲဆုံး အခိုက်အတန့်ပါပဲ။
• စတုတ္ထအပိုင်းသည် ကျွန်ုပ်တို့စစ်ဆေးသည့်အရာဖြစ်သည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် အဘယ်အရာနှင့် နှိုင်းယှဉ်မည်နည်း။ config တွင် တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ဘောင်များကို ပြောင်းလဲနိုင်သည် သို့မဟုတ် အညွှန်းတစ်ခု ဖန်တီးနိုင်သည် စသည်တို့ကို ပြုလုပ်နိုင်သည်ဆိုပါစို့။

ကျွန်ုပ်တို့သည် စမ်းသပ်မှုတစ်ခုကို စတင်နေပါသည်။ ဒါကတော့ pg_stat_statements ပါ။ လက်ဝဲဘက်တွင် ဖြစ်ပျက်ခဲ့သည်။ ညာဘက်တွင်- ဘာဖြစ်သွားတာလဲ။

ဘယ်ဘက်တွင် default_statistics_target = 100၊ ညာဘက်တွင် =1။ ၎င်းသည် ကျွန်ုပ်တို့ကို အထောက်အကူဖြစ်စေကြောင်း ကျွန်ုပ်တို့မြင်သည်။ ယေဘုယျအားဖြင့် 000% ပိုကောင်းလာသည်။

သို့သော် ကျွန်ုပ်တို့ အောက်သို့ဆင်းပါက၊ pgBadger သို့မဟုတ် pg_stat_statements မှ တောင်းဆိုချက်အုပ်စုများ ရှိလိမ့်မည်။ ရွေးချယ်စရာနှစ်ခုရှိသည်။ အချို့သော တောင်းဆိုမှု ၈၈ ရာခိုင်နှုန်း ကျဆင်းသွားသည်ကို တွေ့ရပါမည်။ ဤတွင် အင်ဂျင်နီယာပညာရပ် ချဉ်းကပ်လာပါသည်။ ဘာကြောင့် နစ်မြုပ်သွားတာလဲလို့ သိချင်တဲ့အတွက် အထဲမှာ ထပ်တူးလို့ရတယ်။ စာရင်းဇယားတွေနဲ့ ဖြစ်ပျက်ခဲ့တာတွေကို နားလည်ဖို့ လိုပါတယ်။ စာရင်းဇယားများတွင် ပုံးများ ပိုများနေခြင်းသည် အဘယ်ကြောင့် ပိုဆိုးသော ရလဒ်များကို ဖြစ်စေသနည်း။

သို့မဟုတ် ကျွန်ုပ်တို့တူး၍မရပါ၊ သို့သော် "ALTER TABLE ... ALTER COLUMN" ကိုလုပ်ကာ 100 ပုံးများကို ဤကော်လံ၏စာရင်းအင်းများသို့ ပြန်ပို့ပါ။ ပြီးတော့ နောက်ထပ်စမ်းသပ်မှုတစ်ခုနဲ့ ဒီ patch က အထောက်အကူဖြစ်တယ်ဆိုတာ သေချာအောင်လုပ်နိုင်ပါတယ်။ အားလုံး။ ဤအရာသည် ပင်ကိုယ်ထက် ဒေတာကို အခြေခံ၍ ဆုံးဖြတ်ချက်များချရာတွင် ကျွန်ုပ်တို့အား ရုပ်ပုံကြီးမြင်စေရန် ကူညီပေးသော အင်ဂျင်နီယာပညာရပ်တစ်ခုဖြစ်သည်။

အခြားနယ်ပယ်များမှ ဥပမာအချို့။ နှစ်ပေါင်းများစွာ စမ်းသပ်မှုတွင် CI စမ်းသပ်မှုများ ရှိခဲ့သည်။ အလိုအလျောက်စမ်းသပ်မှုများမပါဘဲ ၎င်း၏စိတ်ကောင်း၌ မည်သည့်ပရောဂျက်မှ အသက်ရှင်မည်မဟုတ်ပါ။

အခြားစက်မှုလုပ်ငန်းများတွင်၊ လေကြောင်း၊ မော်တော်ကားလုပ်ငန်းတွင်၊ ကျွန်ုပ်တို့သည် လေခွင်းအားစမ်းသပ်သောအခါတွင်၊ ကျွန်ုပ်တို့သည် လက်တွေ့စမ်းသပ်မှုများ ပြုလုပ်ရန် အခွင့်အရေးရှိသည်။ ကျွန်ုပ်တို့သည် ပုံဆွဲခြင်းမှ တစ်စုံတစ်ခုကို အာကာသထဲသို့ တိုက်ရိုက်လွှင့်တင်မည်မဟုတ်ပါ၊ သို့မဟုတ် ကျွန်ုပ်တို့သည် ကားလမ်းကြောင်းပေါ်သို့ ချက်ချင်းတက်သွားမည်မဟုတ်ပါ။ ဥပမာ လေတိုက်ဥမင်လိုဏ်ခေါင်းတစ်ခုရှိတယ်။

အခြားစက်မှုလုပ်ငန်းများ၏ လေ့လာတွေ့ရှိချက်များမှ ကျွန်ုပ်တို့ ကောက်ချက်ဆွဲနိုင်သည်။

ပထမဦးစွာ ကျွန်ုပ်တို့တွင် အထူးပတ်ဝန်းကျင်တစ်ခုရှိသည်။ ထုတ်လုပ်မှုနှင့် နီးစပ်သော်လည်း မနီးစပ်ပါ။ ၎င်း၏အဓိကအင်္ဂါရပ်မှာစျေးပေါသည်၊ ထပ်ခါတလဲလဲနှင့်တတ်နိုင်သမျှအလိုအလျောက်လုပ်ဆောင်သင့်သည်။ ထို့အပြင် အသေးစိတ်ခွဲခြမ်းစိတ်ဖြာမှုပြုလုပ်ရန် အထူးကိရိယာများလည်း ရှိရပါမည်။

ဖြစ်နိုင်သည်မှာ ကျွန်ုပ်တို့ လေယာဉ်ကို ပစ်လွှတ်ပြီး ပျံသန်းသောအခါတွင် ကျွန်ုပ်တို့သည် လေတိုက်ဥမင်လိုဏ်ခေါင်းတစ်ခုတွင် ရှိသည်ထက် တောင်ပံမျက်နှာပြင်၏ မီလီမီတာတိုင်းကို လေ့လာရန် အခွင့်အရေးနည်းပါသည်။ ကျွန်ုပ်တို့တွင် နောက်ထပ် ရောဂါရှာဖွေရေးကိရိယာများရှိသည်။ လေယာဉ်ပေါ်မှာ တင်ဖို့ မတတ်နိုင်တဲ့ လေးလံတဲ့ ပစ္စည်းတွေ ပိုသယ်ဖို့ တတ်နိုင်တယ်လေ။ Postgres နဲ့အတူတူပါပဲ။ အချို့ကိစ္စများတွင် ကျွန်ုပ်တို့သည် စမ်းသပ်မှုများအတွင်း ပြည့်စုံသောမေးမြန်းမှုမှတ်တမ်းကို ဖွင့်နိုင်သည်။ ပြီးတော့ ကျွန်တော်တို့ ဒါကို ထုတ်လုပ်မှုမှာ မလုပ်ချင်ဘူး။ ကျွန်ုပ်တို့သည် auto_explain ကို အသုံးပြု၍ ၎င်းကိုဖွင့်ရန်ပင် စီစဉ်နိုင်သည်။

ငါပြောခဲ့သလိုပဲ၊ အလိုအလျောက်စနစ်ရဲ့ မြင့်မားတဲ့အဆင့်က ခလုတ်ကို နှိပ်ပြီး ပြန်လုပ်တာကို ဆိုလိုပါတယ်။ ဒါက ဘယ်လိုဖြစ်သင့်တယ်၊ စမ်းသပ်မှုတွေ အများကြီးရှိလို့ အဲဒါက stream ပေါ်မှာပဲလေ။

Nancy CLI - "ဒေတာဘေ့စ်ဓာတ်ခွဲခန်း" ၏အခြေခံအုတ်မြစ်

ဒါကြောင့် ဒီအရာကို ကျွန်တော်တို့ လုပ်ခဲ့တယ်။ ဆိုလိုတာက လွန်ခဲ့တဲ့ တစ်နှစ်နီးပါးက ဒီစိတ်ကူးတွေကို ဇွန်လမှာ ပြောခဲ့တယ်။ ပြီးတော့ Open Source မှာ Nancy CLI လို့ ခေါ်တဲ့ ကျွန်တော်တို့မှာ ရှိပြီးသားပါ။ ဤသည်မှာ ဒေတာဘေ့စ်ဓာတ်ခွဲခန်းတစ်ခု တည်ဆောက်ခြင်းအတွက် အခြေခံအုတ်မြစ်ဖြစ်သည်။

နန်စီ - ၎င်းသည် Gitlab ရှိ Open Source တွင်ရှိသည်။ သင်ပြောနိုင်၊ သင်ကြိုးစားနိုင်သည်။ ဆလိုက်များတွင် လင့်ခ်တစ်ခု ပေးထားပါသည်။ အဲဒါကို နှိပ်လိုက်ရင် အဲဒီမှာ ပေါ်လာလိမ့်မယ်။ ကူညီပါ ခပ်သိမ်းသောအမှု၌။

ဟုတ်ပါတယ်၊ ဖွံ့ဖြိုးတိုးတက်မှုအောက်မှာအများကြီးရှိသေး၏။ အဲဒီမှာ စိတ်ကူးတွေ အများကြီးရှိတယ်။ ဒါပေမယ့် ဒါက ကျွန်တော်တို့ နေ့တိုင်းနီးပါး သုံးနေတဲ့ အရာပါ။ အကြံတစ်ခုရတဲ့အခါ - လိုင်းပေါင်း 40 ကို ဖျက်လိုက်တဲ့အခါ အားလုံးက IO မှာ ဆင်းသက်လာတာကြောင့် ဘာကြောင့်ဖြစ်သလဲဆိုရင် စမ်းသပ်မှုတစ်ခုပြုလုပ်ပြီး ဘာတွေဖြစ်နေတယ်ဆိုတာကို နားလည်ဖို့ ပိုအသေးစိတ်ကြည့်နိုင်ပြီး သွားရင်းလာရင်းနဲ့ အဲဒါကို ပြင်ဖို့ကြိုးစားပါ။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် စမ်းသပ်မှုတစ်ခု ပြုလုပ်နေပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် တစ်စုံတစ်ခုကို ပြုပြင်ပြောင်းလဲပြီး အဆုံးတွင် ဘာဖြစ်မည်ကို ကြည့်ရှုပါ။ ပြီးတော့ ကျွန်တော်တို့ ဒါကို ထုတ်လုပ်မှုမှာ မလုပ်ပါဘူး။ ဒါက စိတ်ကူးရဲ့ အနှစ်သာရပါ။

ဒီအလုပ်က ဘယ်မှာလဲ။ ၎င်းသည် ပြည်တွင်းတွင် လုပ်ဆောင်နိုင်သည်၊ ဆိုလိုသည်မှာ သင်မည်သည့်နေရာတွင်မဆို ပြုလုပ်နိုင်ပြီး MacBook ပေါ်တွင်ပင် လုပ်ဆောင်နိုင်သည်။ ငါတို့ docker လိုတယ်၊ သွားကြရအောင်။ ဒါပါပဲ။ ၎င်းကို ဟာ့ဒ်ဝဲအစိတ်အပိုင်းတစ်ခုတွင် သို့မဟုတ် အတုအယောင်စက်တစ်ခုတွင် နေရာတိုင်းတွင် သင်လုပ်ဆောင်နိုင်သည်။

ထို့အပြင် EC2 Instance ရှိ Amazon တွင် အဝေးထိန်းစနစ်ဖြင့် လည်ပတ်ရန် အခွင့်အရေးလည်း ရှိပါသည်။ ပြီးတော့ ဒါက အရမ်းကောင်းတဲ့ အခွင့်အရေးပါ။ ဥပမာအားဖြင့်၊ မနေ့က ကျွန်ုပ်တို့သည် အငယ်ဆုံးမှစတင်ကာ i500-3-xlarge ဖြင့်အဆုံးသတ်သော i3 ဥပမာတွင် စမ်းသပ်မှုပေါင်း 16 ကျော်ကို ပြုလုပ်ခဲ့ပါသည်။ စမ်းသပ်မှု ၅၀၀ သည် ကျွန်ုပ်တို့ကို ၆၄ ဒေါ်လာ ကုန်ကျသည်။ တစ်ခုစီသည် 500 မိနစ်ကြာမြင့်သည်။ ဆိုလိုသည်မှာ၊ ထိုနေရာတွင် အစက်အပြောက်များကို အသုံးပြုရသည့်အချက်ကြောင့်၊ ၎င်းသည် အလွန်စျေးပေါသည် - 64% လျှော့စျေး၊ Amazon ၏ တစ်စက္ကန့်ငွေပေးချေမှုဖြစ်သည်။ အများကြီးလုပ်နိုင်တယ်။ စစ်မှန်တဲ့ သုတေသနလုပ်လို့ရတယ်။

နှင့် Postgres ၏ အဓိကဗားရှင်းသုံးမျိုးကိုလည်း ပံ့ပိုးထားသည်။ အဟောင်းအချို့နှင့် 12th ဗားရှင်းအသစ်တို့ကို ပြီးအောင်ပြုလုပ်ရန် ခက်ခဲသည်မဟုတ်ပါ။

အရာဝတ္တုကို သုံးမျိုးဖြင့် သတ်မှတ်နိုင်သည်။ ဤ-

• Dump/sql ဖိုင်။
• အဓိကနည်းလမ်းမှာ PGDATA လမ်းညွှန်ကိုပွားရန်ဖြစ်သည်။ စည်းကမ်းအတိုင်း၊ ၎င်းကို အရန်ဆာဗာမှ ယူသည်။ သင့်တွင် ပုံမှန် binary မိတ္တူများရှိပါက၊ သင်သည် ထိုနေရာမှ clone ပြုလုပ်နိုင်သည်။ သင့်တွင် cloud များရှိပါက Amazon နှင့် Google ကဲ့သို့သော cloud office သည် သင့်အတွက် လုပ်ဆောင်ပေးမည်ဖြစ်သည်။ ဤသည်မှာ အစစ်အမှန်ထုတ်လုပ်မှုကို မွေးထုတ်ရန် အရေးကြီးဆုံးနည်းလမ်းဖြစ်သည်။ ဒါကို ကျွန်တော်တို့ ဖော်ထုတ်တယ်။
• Postgres တွင် တစ်ခုခုအလုပ်လုပ်ပုံကို နားလည်လိုပါက နောက်ဆုံးနည်းလမ်းသည် သုတေသနအတွက် သင့်လျော်ပါသည်။ ဒါက pgbench ပါ။ pgbench ကို အသုံးပြု၍ ဖန်တီးနိုင်သည်။ ၎င်းသည် "db-pgbench" ရွေးချယ်မှုတစ်ခုသာဖြစ်သည်။ ဘယ်အတိုင်းအတာကို ပြောပါသလဲ ။ ဖော်ပြခဲ့သည့်အတိုင်း အရာအားလုံးကို cloud တွင် ထုတ်ပေးမည်ဖြစ်သည်။

နှင့် load-

• SQL thread တစ်ခုတွင် load ကို execute လုပ်နိုင်ပါသည်။ ဤသည်မှာ ရှေးအကျဆုံးနည်းလမ်းဖြစ်သည်။
• ပြီးတော့ ဝန်ကို အတုယူနိုင်တယ်။ ၎င်းကို အောက်ပါနည်းလမ်းများဖြင့် ဦးစွာ အတုယူနိုင်ပါသည်။ သစ်လုံးတွေကို စုဆောင်းရမယ်။ ပြီးတော့ နာကျင်တယ်။ ငါမင်းကိုဘာကြောင့်ပြမယ်။ နန်စီတွင်တည်ဆောက်ထားသည့် pgreplay ကိုအသုံးပြု၍ ကျွန်ုပ်တို့ကစားသည်။
• သို့မဟုတ် အခြားရွေးချယ်မှု။ ပရိယာယ်ဝန်လို့ ခေါ်တဲ့ အတိုင်းအတာတစ်ခုအထိ အားထုတ်ရတယ်။ တိုက်ခိုက်ရေးစနစ်တွင် ကျွန်ုပ်တို့၏လက်ရှိဝန်အား ပိုင်းခြားစိတ်ဖြာခြင်းဖြင့် ကျွန်ုပ်တို့သည် ထိပ်တန်းတောင်းဆိုမှုများ၏ အုပ်စုများကို ဖယ်ရှားပါသည်။ pgbench ကိုသုံးပြီး ဓာတ်ခွဲခန်းမှာ ဒီဝန်ကို အတုယူနိုင်ပါတယ်။

• ကျွန်ုပ်တို့သည် SQL တစ်မျိုးမျိုးကို လုပ်ဆောင်ရမည်ဖြစ်ပြီး၊ ဆိုလိုသည်မှာ ရွှေ့ပြောင်းခြင်းတစ်မျိုးမျိုးကို စစ်ဆေးပါ၊ ထိုနေရာတွင် အညွှန်းတစ်ခုဖန်တီးပါ၊ ထိုနေရာတွင် ANALAZE ကို လုပ်ဆောင်ပါ။ လေဟာနယ် မတိုင်ခင်နဲ့ လေဟာနယ် အပြီးမှာ ဖြစ်ပျက်ခဲ့တာတွေကို ကြည့်ပါ။ ယေဘုယျအားဖြင့် SQL တစ်ခုခု။
• Config တွင် တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ဘောင်များကို ပြောင်းလဲနိုင်သည်။ ကျွန်ုပ်တို့၏ terabyte ဒေတာဘေ့စ်အတွက် Amazon ရှိ 100 တန်ဘိုးများကို စစ်ဆေးရန် ကျွန်ုပ်တို့အား ပြောနိုင်ပါသည်။ နာရီအနည်းငယ်အတွင်း ရလဒ်ကို ရရှိမည်ဖြစ်သည်။ စည်းကမ်းအတိုင်း၊ terabyte ဒေတာဘေ့စ်ကို အသုံးပြုရန် နာရီပေါင်းများစွာ ကြာပါမည်။ သို့သော် ဖွံ့ဖြိုးတိုးတက်မှုတွင် patch တစ်ခုရှိသည်၊ ကျွန်ုပ်တို့တွင် ဖြစ်နိုင်ချေရှိသော စီးရီးတစ်ခုရှိသည်၊ ဆိုလိုသည်မှာ သင်သည် တူညီသော pgdata ကို တူညီသောဆာဗာပေါ်တွင် တစ်သမတ်တည်းသုံး၍ စစ်ဆေးနိုင်သည်။ Postgres ပြန်လည်စတင်မည်ဖြစ်ပြီး ကက်ရှ်များကို ပြန်လည်သတ်မှတ်ပါမည်။ ဝန်ကို နှင်နိုင်သည်။

• pg လျှပ်တစ်ပြက်ရိုက်ချက်များမှအစပြု၍ မတူညီသောဖိုင်များစွာဖြင့် လမ်းညွှန်တစ်ခုရောက်ရှိလာသည်။Statဟုတ်လား။ ပြီးတော့ စိတ်ဝင်စားစရာအကောင်းဆုံးကတော့ pg_stat_statements၊ pg_stat_kacke ပါ။ ဤအရာများသည် တောင်းဆိုမှုများကို ခွဲခြမ်းစိတ်ဖြာသည့် တိုးချဲ့မှုနှစ်ခုဖြစ်သည်။ ထို့အပြင် pg_stat_bgwriter တွင် pgwriter စာရင်းဇယားများသာမက စစ်ဆေးရေးဂိတ်နှင့် နောက်ခံများသည် ညစ်ပတ်သောကြားခံများကို မည်ကဲ့သို့ ရွှေ့ပြောင်းပေးပုံတို့ပါရှိသည်။ ပြီးတော့ အားလုံးက စိတ်ဝင်စားဖို့ကောင်းတယ်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် shared_buffers ကို စနစ်ထည့်သွင်းသောအခါ၊ လူတိုင်းကို မည်မျှ အစားထိုးထားသည်ကို ကြည့်ရှုရန် အလွန်စိတ်ဝင်စားစရာကောင်းပါသည်။
• Postgres မှတ်တမ်းများလည်း ရောက်ရှိလာပါသည်။ မှတ်တမ်းနှစ်ခု - ပြင်ဆင်မှုမှတ်တမ်းနှင့် ဖွင့်ဖွင့်ခြင်းမှတ်တမ်း။
• အတော်လေးအသစ်သောအင်္ဂါရပ်မှာ FlameGraphs ဖြစ်သည်။
• ထို့အပြင်၊ သင်သည် pgreplay သို့မဟုတ် pgbench ရွေးစရာများကိုအသုံးပြုပါက၊ ၎င်းတို့၏ထွက်အားသည် မူရင်းဖြစ်လိမ့်မည်။ နှင့် latency နှင့် TPS ကိုသင်တွေ့လိမ့်မည်။ အဲဒါကို သူတို့ ဘယ်လိုမြင်လဲဆိုတာ နားလည်လာလိမ့်မယ်။
• စနစ်အချက်အလက်။
• အခြေခံ CPU နှင့် IO စစ်ဆေးမှုများ။ ၎င်းသည် Amazon ရှိ EC2 instance အတွက် ပိုကောင်းသည်၊၊ သင်သည် thread တစ်ခုတွင် ထပ်တူထပ်မျှသော ဖြစ်ရပ်ပေါင်း 100 ကိုဖွင့်ပြီး ထိုနေရာတွင် မတူညီသော အပြေးပေါင်း 100 ကို run လိုပါက၊ သင်သည် စမ်းသပ်မှု 10 ရှိလိမ့်မည်။ ပြီးတော့ တစ်စုံတစ်ယောက်ရဲ့ ဖိနှိပ်မှုကို ခံနေရပြီးဖြစ်တဲ့ ချို့ယွင်းချက်ရှိတဲ့ ဥပမာတစ်ခုကို သင်မတွေ့မိကြောင်း သေချာဖို့ လိုပါတယ်။ အခြားသူများသည် ဤဟာ့ဒ်ဝဲအပိုင်းတွင် အသုံးပြုနေပြီး သင့်တွင် အရင်းအမြစ်အနည်းငယ်သာ ကျန်ရှိတော့သည်။ ထိုသို့သောရလဒ်များကို စွန့်ပစ်ခြင်းသည် ပိုကောင်းသည်။ Alexey Kopytov မှ sysbench ၏အကူအညီဖြင့်၊ ကျွန်ုပ်တို့သည် အခြားသူများနှင့် နှိုင်းယှဉ်နိုင်သည့် အတိုချုံးစစ်ဆေးမှုများစွာကို ပြုလုပ်သည်၊ ဆိုလိုသည်မှာ CPU ၏အပြုအမူနှင့် IO ပြုမူပုံကို သင်နားလည်မည်ဖြစ်သည်။

ကွဲပြားခြားနားသောကုမ္ပဏီများ၏ဥပမာအပေါ်အခြေခံပြီးနည်းပညာဆိုင်ရာအခက်အခဲများဘာတွေလဲ။

မှတ်တမ်းများကို အသုံးပြု၍ အစစ်အမှန် load ကို ထပ်လုပ်လိုသည်ဆိုပါစို့။ Open Source pgreplay မှာ ရေးထားရင် ကောင်းပါတယ်။ အဲဒါကို သုံးပါတယ်။ သို့သော် ၎င်းသည် ကောင်းမွန်စွာအလုပ်လုပ်ရန်အတွက်၊ သင်သည် ကန့်သတ်ချက်များနှင့် အချိန်ကိုက်မှုဖြင့် ပြည့်စုံသောမေးမြန်းမှုမှတ်တမ်းကို ဖွင့်ရပါမည်။

ကြာချိန်နှင့် အချိန်တံဆိပ်ရိုက်ခြင်းဆိုင်ရာ ရှုပ်ထွေးမှုများ ရှိပါသည်။ ဒီမီးဖိုခန်းတစ်ခုလုံးကို ငါတို့ လွတ်သွားမယ်။ အဓိက မေးချင်တာက မင်း တတ်နိုင်လား မတတ်နိုင်ဘူးလား။

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

ပြဿနာက မရနိုင်ပါ။ ပထမဦးစွာ၊ မှတ်တမ်းတွင် မည်သည့်စီးကြောင်းကို ရေးသားမည်ကို နားလည်ရပါမည်။ သင့်တွင် pg_stat_statements များရှိပါက၊ သင်သည် တစ်စက္ကန့်လျှင် မည်မျှ bytes မည်မျှရေးသားမည်ကို ခန့်မှန်းနားလည်ရန် ဤမေးမြန်းချက် (လင့်ခ်ကို ဆလိုက်များတွင် ရနိုင်ပါမည်) ကို အသုံးပြုနိုင်ပါသည်။

တောင်းဆိုချက်ရဲ့ အရှည်ကို ကြည့်တယ်။ ကန့်သတ်ချက်များမရှိဟူသောအချက်ကို ကျွန်ုပ်တို့ လျစ်လျူရှုနေသော်လည်း တောင်းဆိုချက်၏ကြာချိန်ကို သိရှိပြီး တစ်စက္ကန့်လျှင် အကြိမ်မည်မျှလုပ်ဆောင်သည်ကို သိရှိပါသည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် တစ်စက္ကန့်လျှင် ဘိုက်မည်မျှ ခန့်မှန်းနိုင်သည် ။ ကျွန်ုပ်တို့သည် နှစ်ဆလောက် အမှားလုပ်မိနိုင်သော်လည်း ဤနည်းဖြင့် အမိန့်ကို ကျိန်းသေနားလည်ပါမည်။

ဤတောင်းဆိုချက်ကို တစ်စက္ကန့်လျှင် 802 ကြိမ် လုပ်ဆောင်ကြောင်း ကျွန်ုပ်တို့တွေ့မြင်နိုင်ပါသည်။ bytes_per sec – 300 kB/s ကို အပေါင်း သို့မဟုတ် အနုတ်ဟု ရေးထားသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရသည်။ စည်းကမ်းအတိုင်း၊ ငါတို့သည်ထိုကဲ့သို့သောစီးဆင်းမှုကိုတတ်နိုင်သည်။

ဒါပေမယ့်! အမှန်မှာ မတူညီသော သစ်ခုတ်ခြင်းစနစ်များ ရှိပါသည်။ လူတို့၏ ပုံသေသည် အများအားဖြင့် "syslog" ဖြစ်သည်။

အကယ်၍ သင့်တွင် syslog ရှိလျှင် ဤကဲ့သို့သော ပုံတစ်ပုံရှိနိုင်သည်။ ကျွန်ုပ်တို့သည် pgbench ကိုယူ၍ query logging ကိုဖွင့်ပြီး ဘာဖြစ်သွားသည်ကိုကြည့်ပါမည်။

မှတ်တမ်းမပါဘဲ - ဤသည်မှာ ဘယ်ဘက်ရှိ ကော်လံဖြစ်သည်။ ကျွန်ုပ်တို့သည် 161 TPS ရရှိသည်။ syslog ဖြင့် - ၎င်းသည် Amazon ရှိ Ubuntu 000 တွင်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် 16.04 TPS ရရှိသည်။ အခြားသစ်ခုတ်ခြင်းနည်းလမ်းနှစ်ခုသို့ ပြောင်းလျှင် အခြေအနေက ပိုကောင်းပါသည်။ ဆိုလိုတာက ကျဆင်းမယ်လို့ ကျွန်တော်တို့ မျှော်လင့်ထားပေမယ့် အတိုင်းအတာတစ်ခုအထိတော့ မဟုတ်ပါဘူး။

ထို့အပြင် ဂျာနယ်လည်းပါဝင်သည့် CentOS 7 တွင် မှတ်တမ်းများကို လွယ်ကူစွာရှာဖွေရန်အတွက် binary ဖော်မတ်အဖြစ်သို့ပြောင်းသည်၊ ထို့နောက်တွင် အိပ်မက်ဆိုးတစ်ခုဖြစ်လာသည်၊ TPS တွင် 44 ကြိမ်ချပေးပါသည်။

ပြီးတော့ ဒါက လူတွေနဲ့ အတူနေထိုင်တယ်။ အထူးသဖြင့် ကုမ္ပဏီကြီးများတွင် မကြာခဏ ပြောင်းလဲရန် အလွန်ခက်ခဲသည်။ အကယ်၍ သင်သည် syslog မှ လွတ်မြောက်နိုင်လျှင် ကျေးဇူးပြု၍ ၎င်းနှင့် ဝေးရာသို့ ထွက်ခွာပါ။

• IOPS ကိုအကဲဖြတ်ပြီး flow ကိုရေးပါ။
• သင်၏မှတ်တမ်းစနစ်အား စစ်ဆေးပါ။
• projected load သည် အလွန်ကြီးမားပါက၊ နမူနာယူရန် စဉ်းစားပါ။

ကျွန်ုပ်တို့တွင် pg_stat_statement များရှိသည်။ ငါပြောသလိုပဲ၊ အဲဒါရှိရမယ်။ ထို့အပြင် ကျွန်ုပ်တို့သည် တောင်းဆိုချက်အုပ်စုတစ်ခုစီကို ဖိုင်တစ်ခုတွင် အထူးနည်းလမ်းဖြင့် ရယူပြီး ဖော်ပြနိုင်ပါသည်။ ထို့နောက် pgbench တွင် အလွန်အဆင်ပြေသောအင်္ဂါရပ်ကို ကျွန်ုပ်တို့အသုံးပြုနိုင်သည် - ၎င်းသည် “-f” ရွေးချယ်မှုကို အသုံးပြု၍ ဖိုင်များစွာကို ထည့်သွင်းနိုင်သည်။

"-f" ကို အများကြီး နားလည်တယ်။ ပြီးတော့ ဖိုင်တစ်ခုစီမှာ မျှဝေထားသင့်တဲ့အရာတွေကို အဆုံးမှာ “@” ရဲ့အကူအညီနဲ့ သင်ပြောပြနိုင်ပါတယ်။ ဆိုလိုသည်မှာ၊ ကိစ္စများ၏ 10% တွင်၊ 20% တွင်ပြုလုပ်သည်ဟုကျွန်ုပ်တို့ပြောနိုင်သည်။ ၎င်းသည် ကျွန်ုပ်တို့ကို ထုတ်လုပ်ရေးတွင် မြင်တွေ့ရသည့်အရာနှင့် ပိုမိုနီးစပ်စေမည်ဖြစ်သည်။

ထုတ်လုပ်မှုတွင် ကျွန်ုပ်တို့၏အရာများကို ကျွန်ုပ်တို့ မည်သို့နားလည်မည်နည်း။ ဘယ်လိုမျှဝေမလဲ၊ ဒါက နည်းနည်းတော့ လွဲနေတယ်။ ကျွန်ုပ်တို့တွင် နောက်ထပ်ထုတ်ကုန်တစ်ခုရှိသည်။ postgres-စစ်ဆေးခြင်း။. Open Source တွင်လည်း အခြေခံဖြစ်သည်။ ယခု ကျွန်ုပ်တို့သည် ၎င်းကို တက်ကြွစွာ ဖော်ဆောင်လျက်ရှိသည်။

အကြောင်းအမျိုးမျိုးကြောင့် မွေးဖွားလာသူဖြစ်သည်။ စောင့်ကြည့်မှု မလုံလောက်သော အကြောင်းရင်းများကြောင့် ဖြစ်သည်။ ဆိုလိုသည်မှာ သင်လာပါ၊ အခြေခံကိုကြည့်ပါ၊ တည်ရှိနေသောပြဿနာများကိုကြည့်ပါ။ စည်းကမ်းအတိုင်း၊ သင်သည် ကျန်းမာရေးစစ်ဆေးမှုကို ပြုလုပ်သည်။ အကယ်၍ သင်သည် အတွေ့အကြုံရှိသော DBA ဖြစ်ပါက၊ သင်သည် ကျန်းမာရေးစစ်ဆေးမှုကို ပြုလုပ်ပါ။ အညွှန်းများအသုံးပြုမှုစသည်တို့ကို ကျွန်ုပ်တို့ကြည့်ရှုခဲ့ပါသည်။ သင့်တွင် OKmeter ရှိလျှင်ကောင်းပါသည်။ ဤသည်မှာ Postgres အတွက် အေးမြသော စောင့်ကြည့်မှုဖြစ်သည်။ OKmeter.io - ကျေးဇူးပြု၍ ၎င်းကိုထည့်သွင်းပါ၊ အရာအားလုံးသည်အလွန်ကောင်းမွန်ပါသည်။ ပေးဆောင်ပြီးပါပြီ။

သင့်မှာ တစ်ခုမှမရှိရင် များသောအားဖြင့် သင့်မှာ အများကြီးမရှိပါဘူး။ စောင့်ကြည့်မှုတွင်၊ များသောအားဖြင့် CPU၊ IO၊ ထို့နောက် ကြိုတင်စာရင်းသွင်းမှုများ ရှိကြပြီး၊ ဒါပါပဲ။ ပြီးတော့ ငါတို့ ပိုလိုတယ်။ autovacuum အလုပ်လုပ်ပုံ၊ checkpoint အလုပ်လုပ်ပုံ၊ io တွင် checkpoint ကို bgwriter နှင့် backends တို့မှ ခွဲခြားရန် လိုအပ်သည် ။

ပြဿနာက ကုမ္ပဏီကြီးတစ်ခုကို ကူညီပေးတဲ့အခါ သူတို့က တစ်ခုခုကို မြန်မြန်ဆန်ဆန် အကောင်အထည်မဖော်နိုင်လို့ပါပဲ။ OKmeter ကို အမြန်မဝယ်နိုင်ကြပါ။ ခြောက်လအကြာတွင် သူတို့ဝယ်နိုင်မည်ဖြစ်သည်။ အချို့သော ပက်ကေ့ခ်ျများကို အမြန်မပို့နိုင်ကြပါ။

ပြီးတော့ တပ်ဆင်ဖို့ ဘာမှမလိုအပ်တဲ့ အထူးကိရိယာတစ်ခုလိုတယ်၊ ဆိုလိုသည်မှာ သင်သည် ထုတ်လုပ်ရေးတွင် မည်သည့်အရာကိုမျှ တပ်ဆင်ရန် မလိုဟု အကြံတစ်ခုရလာသည်။ ၎င်းကို သင့်လက်ပ်တော့ပေါ်တွင် တပ်ဆင်ပါ သို့မဟုတ် သင်လုပ်ဆောင်မည့်နေရာမှ စောင့်ကြည့်လေ့လာသည့် ဆာဗာတွင် ထည့်သွင်းပါ။ ၎င်းသည် အရာများစွာကို ခွဲခြမ်းစိတ်ဖြာလိမ့်မည်- လည်ပတ်မှုစနစ်၊ ဖိုင်စနစ်နှင့် Postgres ကိုယ်တိုင်က ထုတ်လုပ်ခြင်းသို့ တိုက်ရိုက်လည်ပတ်နိုင်သည့် ပေါ့ပါးသောမေးခွန်းအချို့ကို ပြုလုပ်ပြီး မည်သည့်အရာမှ ပျက်ကွက်မည်မဟုတ်ပါ။

အဲဒါကို Postgres-checkup လို့ခေါ်တယ်။ ဆေးပညာအရ၊ ဤသည်မှာ ပုံမှန်ကျန်းမာရေးစစ်ဆေးခြင်း ဖြစ်သည်။ မော်တော်ယာဥ်ပုံစံဖြစ်လျှင် ပြုပြင်ထိန်းသိမ်းမှုကဲ့သို့ပင်။ အမှတ်တံဆိပ်ပေါ်မူတည်၍ သင့်ကားကို ခြောက်လတစ်ကြိမ် သို့မဟုတ် တစ်နှစ်လျှင် ပြုပြင်ထိန်းသိမ်းမှု ပြုလုပ်ပါသည်။ သင့်အခြေခံအတွက် ပြုပြင်ထိန်းသိမ်းမှု ပြုလုပ်ပါသလား။ ဆိုလိုသည်မှာ သင်သည် နက်ရှိုင်းသော သုတေသနကို ပုံမှန်လုပ်ပါသလား။ အဲဒါကို လုပ်ရမယ်။ အကယ်၍ သင်သည် အရန်ကူးယူမှုများ ပြုလုပ်ပြီးနောက် စစ်ဆေးမှုပြုလုပ်ပါက၊ ၎င်းသည် အရေးမကြီးပါ။

ပြီးတော့ ငါတို့မှာ ဒီလိုကိရိယာရှိတယ်။ လွန်ခဲ့သည့် သုံးလခန့်ကပင် တက်ကြွစွာ ပေါ်ပေါက်လာခဲ့သည်။ သူက ငယ်သေးပေမယ့် အများကြီး ရှိသေးတယ်။

မေးခွန်းများ၏ “သြဇာအရှိဆုံး” အုပ်စုများကို စုဆောင်းခြင်း - Postgres-စစ်ဆေးခြင်းတွင် K003 ကို အစီရင်ခံပါ။

ယခုအချိန်အထိ K. အစီရင်ခံစာ ၃ စောင်အုပ်စုရှိနေသည်။ K003 အစီရင်ခံစာလည်း ရှိတယ်။ Total_time ဖြင့် စီထားသော pg_stat_statements မှ ထိပ်တန်း ရှိပါသည်။

တောင်းဆိုချက်အုပ်စုများကို Total_time ဖြင့် စီစစ်သောအခါ၊ ထိပ်တွင် ကျွန်ုပ်တို့၏စနစ်အား အများဆုံးတင်ဆောင်သည့်အုပ်စုကို တွေ့ရသည်၊ ဆိုလိုသည်မှာ အရင်းအမြစ်များကို ပိုမိုသုံးစွဲသည်။ ကျွန်ုပ်သည် မေးမြန်းမှုအဖွဲ့များကို အဘယ်ကြောင့် အမည်ပေးသနည်း။ ဘာလို့လဲဆိုတော့ ကျွန်တော်တို့က ဘောင်တွေကို ထုတ်ပစ်လိုက်တယ်။ ၎င်းတို့သည် တောင်းဆိုမှုများမဟုတ်တော့ဘဲ တောင်းဆိုချက်အုပ်စုများဖြစ်သော၊ ဆိုလိုသည်မှာ ၎င်းတို့သည် လွဲချော်နေပါသည်။

ကျွန်ုပ်တို့သည် အထက်မှအောက်သို့ အကောင်းဆုံးဖြစ်အောင်လုပ်ပါက၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏အရင်းအမြစ်များကို ပေါ့ပါးစေပြီး အဆင့်မြှင့်ရန်လိုအပ်သည့်အချိန်ကို နှောင့်နှေးစေမည်ဖြစ်သည်။ ဤသည်မှာ ငွေစုရန် အလွန်ကောင်းသော နည်းလမ်းဖြစ်သည်။

ရှားရှားပါးပါး၊ လူတစ်ဦး 15 စက္ကန့်စောင့်ရသည့် အလွန်စိတ်အနှောင့်အယှက်ဖြစ်စရာ ကိစ္စများကို ကျွန်ုပ်တို့ မတွေ့နိုင်သောကြောင့် အသုံးပြုသူများကို ဂရုစိုက်ရန် ဤနည်းလမ်းသည် အလွန်ကောင်းမွန်သောနည်းလမ်းမဟုတ်ပေ။ စုစုပေါင်း၊ ၎င်းတို့သည် အလွန်ရှားပါးသော်လည်း ကျွန်ုပ်တို့သည် ၎င်းတို့ကို မမြင်နိုင်သော်လည်း အရင်းအမြစ်များနှင့် ပတ်သက်ပါသည်။

ဒီဇယားမှာ ဘာဖြစ်သွားတာလဲ။ လျှပ်တစ်ပြက် နှစ်ခု ရိုက်တယ်။ Postgres_checkup သည် သင့်အား မက်ထရစ်တစ်ခုစီအတွက် မြစ်ဝကျွန်းပေါ်ကို ပေးလိမ့်မည်- စုစုပေါင်းအချိန်၊ ခေါ်ဆိုမှုများ၊ အတန်းများ၊ shared_blks_read စသဖြင့်၊ ဒါပဲ၊ မြစ်ဝကျွန်းပေါ်ကို တွက်ချက်ပြီးပါပြီ။ pg_stat_statements ၏ကြီးမားသောပြဿနာမှာ ၎င်းကို ပြန်လည်သတ်မှတ်သည့်အခါတွင် မမှတ်မိခြင်းပင်ဖြစ်သည်။ pg_stat_database မှတ်မိပါက pg_stat_statements များကို မမှတ်မိပါ။ 1 အရေအတွက်ကို သင်တွေ့မြင်ရသော်လည်း မည်သည့်နေရာမှ ရေတွက်သည်ကို ကျွန်ုပ်တို့မသိပါ။

ဒီမှာ ငါတို့သိတယ်၊ ဒီမှာ လျှပ်တစ်ပြက်နှစ်ချက်ရှိတယ်။ ဤကိစ္စတွင် မြစ်ဝကျွန်းပေါ်ဒေသသည် ၅၆ စက္ကန့်ဖြစ်ကြောင်း ကျွန်ုပ်တို့သိသည်။ အလွန်တိုတောင်းသောကွာဟချက်။ Total_time ဖြင့် စီထားသည်။ ထို့နောက် ကျွန်ုပ်တို့ ခွဲခြားနိုင်သည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် မက်ထရစ်အားလုံးကို ကြာချိန်ဖြင့် ပိုင်းခြားနိုင်သည်။ ကျွန်ုပ်တို့သည် မက်ထရစ်တစ်ခုစီကို ကြာချိန်ဖြင့် ပိုင်းခြားပါက၊ ကျွန်ုပ်တို့သည် တစ်စက္ကန့်လျှင် ဖုန်းခေါ်ဆိုမှုအရေအတွက်ကို ရရှိမည်ဖြစ်သည်။

ထို့နောက်၊ စုစုပေါင်း_အချိန်သည် တစ်စက္ကန့်လျှင် ကျွန်ုပ်အကြိုက်ဆုံးမက်ထရစ်ဖြစ်သည်။ ၎င်းကို စက္ကန့်အလိုက်၊ တစ်စက္ကန့်လျှင် တိုင်းတာသည်၊ ဆိုလိုသည်မှာ ဤတောင်းဆိုချက်အုပ်စုကို လုပ်ဆောင်ရန် ကျွန်ုပ်တို့၏စနစ်သည် တစ်စက္ကန့်လျှင် စက္ကန့်မည်မျှကြာသည်။ အဲဒီမှာ တစ်စက္ကန့်ကို တစ်စက္ကန့်ထက် ပိုမြင်ရင် core တစ်ခုထက် ပိုပေးရမယ်လို့ ဆိုလိုပါတယ်။ ဤသည်မှာ အလွန်ကောင်းမွန်သော မက်ထရစ်တစ်ခုဖြစ်သည်။ ဥပမာ၊ ဤမိတ်ဆွေသည် အနည်းဆုံး core သုံးခု လိုအပ်ကြောင်း သင်နားလည်နိုင်သည်။

ဒါက ငါတို့ရဲ့အတတ်ပညာပဲ၊ ငါဘယ်နေရာမှာမှ ဒီလိုမျိုး တစ်ခါမှမတွေ့ဖူးဘူး။ ကျေးဇူးပြု၍ သတိပြုပါ - ဤအရာသည် အလွန်ရိုးရှင်းသော အရာဖြစ်သည် - တစ်စက္ကန့်လျှင် တစ်စက္ကန့်။ တစ်ခါတစ်ရံတွင် သင်၏ CPU သည် 100% ဖြစ်သောအခါ တစ်စက္ကန့်လျှင် နာရီဝက်၊ ဆိုလိုသည်မှာ သင်သည် ဤတောင်းဆိုမှုများကို လုပ်ဆောင်ရန် နာရီဝက်ကြာအောင် အချိန်ယူနေပါသည်။

ထို့နောက် တစ်စက္ကန့်လျှင် အတန်းများကို ကြည့်သည်။ တစ်စက္ကန့်လျှင် အတန်းဘယ်နှစ်တန်း ပြန်တက်သည်ကို ကျွန်ုပ်တို့သိသည်။

ပြီးတော့ စိတ်ဝင်စားစရာတစ်ခုလည်း ရှိတယ်။ shared_buffers ကိုယ်တိုင်မှ တစ်စက္ကန့်လျှင် shared_buffers ဘယ်လောက်ဖတ်လဲ။ ထိတ်လန့်မှုများသည် ထိုနေရာတွင်ရှိပြီး၊ ကျွန်ုပ်တို့သည် လည်ပတ်မှုစနစ် ကက်ရှ် သို့မဟုတ် ဒစ်ခ်မှ အတန်းများကို ယူထားသည်။ ပထမရွေးချယ်မှုသည် မြန်သည်၊ ဒုတိယသည် အခြေအနေပေါ်မူတည်၍ မြန်နိုင်သည် သို့မဟုတ် မမြန်နိုင်ပါ။

ကွဲပြားခြင်း၏ ဒုတိယနည်းလမ်းမှာ ဤအုပ်စုရှိ တောင်းဆိုမှုအရေအတွက်ကို ပိုင်းခြားရန်ဖြစ်သည်။ ဒုတိယကော်လံတွင် သင့်တွင် query တစ်ခုစီကို အမြဲတမ်းခွဲထားသည်။ ပြီးတော့ စိတ်ဝင်စားစရာကောင်းတာက ဒီတောင်းဆိုချက်မှာ မီလီစက္ကန့်ဘယ်လောက်ရှိလဲ။ ဤမေးခွန်းသည် ပျမ်းမျှအားဖြင့် မည်သို့ပြုမူသည်ကို ကျွန်ုပ်တို့သိပါသည်။ တောင်းဆိုချက်တစ်ခုစီအတွက် 101 မီလီစက္ကန့် လိုအပ်သည်။ ဤသည်မှာ ကျွန်ုပ်တို့နားလည်ရန်လိုအပ်သည့် ရိုးရာမက်ထရစ်ဖြစ်သည်။

မေးခွန်းတစ်ခုစီသည် ပျမ်းမျှအားဖြင့် အတန်းဘယ်နှစ်တန်း ပြန်တက်ခဲ့သနည်း။ 8 ဒီအဖွဲ့ ပြန်လာတာကို တွေ့တယ်။ ပျမ်းမျှအားဖြင့် ကက်ရှ်မှ မည်မျှယူ၍ ဖတ်ရှုသည်။ အရာအားလုံးကို ကောင်းမွန်စွာ သိမ်းဆည်းထားသည်ကို ကျွန်ုပ်တို့မြင်သည်။ ပထမအုပ်စုအတွက် အကြိတ်အနယ်တွေ့သည်။

စာကြောင်းတစ်ခုစီရှိ စတုတ္ထတန်းခွဲသည် စုစုပေါင်း၏ ရာခိုင်နှုန်းဖြစ်သည်။ ကျွန်ုပ်တို့တွင် ဖုန်းခေါ်ဆိုမှုများ ရှိသည်။ 1 ဆိုကြပါစို့။ ပြီးတော့ ဒီအဖွဲ့ရဲ့ အလှူငွေက ဘာကို ပေးတယ်ဆိုတာ နားလည်နိုင်တယ်။ ဤကိစ္စတွင် ပထမအုပ်စုသည် 000% ထက်နည်းသည်ဟု ကျွန်ုပ်တို့မြင်သည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် ၎င်းကို အလုံးစုံပုံတွင် မမြင်နိုင်လောက်အောင် နှေးကွေးနေပါသည်။ ဒုတိယအုပ်စုသည် ဖုန်းခေါ်ဆိုမှုတွင် 000% ဖြစ်သည်။ ဆိုလိုသည်မှာ ဖုန်းခေါ်ဆိုမှုအားလုံး၏ 0,01% သည် ဒုတိယအုပ်စုဖြစ်သည်။

Total_time သည်လည်း စိတ်ဝင်စားစရာကောင်းသည်။ ကျွန်ုပ်တို့သည် တောင်းဆိုချက်များ၏ ပထမအုပ်စုတွင် ကျွန်ုပ်တို့၏ စုစုပေါင်းအလုပ်ချိန်၏ 14% ကို အသုံးပြုခဲ့သည်။ ဒုတိယအတွက် - 11% စသည်တို့ဖြစ်သည်။

အသေးစိတ်တော့ မပြောတော့ပါဘူး၊ ဒါပေမယ့် အဲဒီမှာ သိမ်ငယ်စိတ်တွေ ရှိတယ်။ ကျွန်ုပ်တို့သည် နှိုင်းယှဉ်သောအခါတွင် လျှပ်တစ်ပြက်ရိုက်ချက်များ လွင့်နေနိုင်သောကြောင့် ထိပ်တွင် ကျွန်ုပ်တို့သည် အမှားအယွင်းတစ်ခုကို ပြနေပါသည်၊ ဆိုလိုသည်မှာ အချို့သောတောင်းဆိုမှုများသည် ပျက်သွားနိုင်ပြီး ဒုတိယတစ်ခုတွင် ရှိနေနိုင်တော့မည်မဟုတ်ပါ၊ အချို့သောအသစ်များလည်း ပေါ်လာနိုင်ပါသည်။ အဲဒီမှာ အမှားကို တွက်တယ်။ 0 ကိုတွေ့ရင် ကောင်းပါတယ်။ အမှားအယွင်းမရှိပါ။ အမှားအယွင်းနှုန်းသည် 20% အထိရှိနေပါက၊ အိုကေ။

ထို့နောက် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ ခေါင်းစဉ်သို့ ပြန်သွားကြသည်။ ကျွန်ုပ်တို့သည် အလုပ်တာဝန်ကို ထမ်းဆောင်ရန် လိုအပ်ပါသည်။ အပေါ်ကနေ အောက်ကိုယူပြီးတော့ 80% ဒါမှမဟုတ် 90% ရောက်တဲ့အထိ သွားပါ။ များသောအားဖြင့် 10-20 အုပ်စုဖြစ်သည်။ ပြီးတော့ pgbench အတွက် ဖိုင်တွေ လုပ်တယ်။ အဲဒီမှာ ကျပန်းသုံးတယ်။ တစ်ခါတစ်ရံတွင် ဤအရာသည် ကံမကောင်းစွာဖြင့် အလုပ်မဖြစ်ပါ။ နှင့် Postgres 12 တွင် ဤချဉ်းကပ်မှုကို အသုံးပြုရန် အခွင့်အလမ်းများ ပိုမိုရှိလာမည်ဖြစ်သည်။

ထို့နောက် ဤနည်းဖြင့် စုစုပေါင်း_အချိန် 80-90% ရရှိသည်။ “@” ပြီးနောက် ဘာကိုဆက်ရမလဲ။ ခေါ်ဆိုမှုများကိုကြည့်ကာ အတိုးမည်မျှရှိသည်ကိုကြည့်ကာ ဤနေရာတွင် အတိုးများစွာပေးဆောင်ကြောင်း နားလည်ပါသည်။ ဤရာခိုင်နှုန်းများမှ ဖိုင်တစ်ခုစီကို ဟန်ချက်ညီအောင် မည်သို့လုပ်ဆောင်ရမည်ကို ကျွန်ုပ်တို့ နားလည်နိုင်ပါသည်။ ထို့နောက် pgbench ကိုသုံး၍ အလုပ်သွားပါ။

K001 နှင့် K002 လည်းရှိသည်။

K001 သည် စာကြောင်းလေးခုပါသော ကြိုးတန်းကြီးတစ်ခုဖြစ်သည်။ ဤသည်မှာ ကျွန်ုပ်တို့၏ ဝန်တစ်ခုလုံး၏ လက္ခဏာတစ်ရပ်ဖြစ်သည်။ ဒုတိယကော်လံနှင့် ဒုတိယတန်းခွဲကို ကြည့်ပါ။ တစ်စက္ကန့်လျှင် တစ်စက္ကန့်ခွဲခန့်ရှိသည်၊ ဆိုလိုသည်မှာ Core နှစ်ခုရှိလျှင် ကောင်းလိမ့်မည်။ ခန့်မှန်းခြေအားဖြင့် 75% ရှိမည်ဖြစ်သည်။ ပြီးတော့ ဒီပုံစံအတိုင်း အလုပ်လုပ်လိမ့်မယ်။ ကျွန်ုပ်တို့တွင် core 10 ရှိပါက၊ ကျွန်ုပ်တို့သည် ယေဘူယျအားဖြင့် ငြိမ်သက်နေလိမ့်မည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် အရင်းအမြစ်များကို အကဲဖြတ်နိုင်သည်။

K002 သည် query classes ဟုခေါ်သည် ၊ ဆိုလိုသည်မှာ SELECT, INSERT, UPDATE, DELETE. လော့ခ်တစ်ခုဖြစ်သောကြောင့် UPDATE အတွက် သီးခြားစီ SELECT ။

ဤနေရာတွင် SELECT သည် သာမန်စာဖတ်သူများဖြစ်သည် - ခေါ်ဆိုမှုအားလုံး၏ 82% ဖြစ်သော်လည်း တစ်ချိန်တည်းတွင် - စုစုပေါင်း_time တွင် 74% ဖြစ်သည်။ ဆိုလိုသည်မှာ ၎င်းတို့ကို များစွာခေါ်ဝေါ်ကြသော်လည်း အရင်းအမြစ်များကို နည်းပါးစွာ စားသုံးကြသည်။

ပြီးလျှင် ကျွန်ုပ်တို့သည် မေးခွန်းဆီသို့ ပြန်သွားသည်- "မှန်ကန်သော shared_buffers ကို ကျွန်ုပ်တို့ မည်သို့ ရွေးချယ်နိုင်မည်နည်း။" စံသတ်မှတ်ချက်အများစုသည် အိုင်ဒီယာပေါ်တွင် အခြေခံထားကြောင်း ကျွန်ုပ်သတိပြုမိသည် - ဖြတ်သန်းမှုမှာ မည်သည့်အရာဖြစ်မည်၊ ဆိုလိုသည်မှာ ဖြတ်သန်းမှု မည်သို့ဖြစ်မည်ကို ကြည့်ကြပါစို့။ ၎င်းကို TPS သို့မဟုတ် QPS ဖြင့် တိုင်းတာသည်။

ပြီးတော့ tuning parameters တွေကိုသုံးပြီး ကားထဲကနေ တတ်နိုင်သမျှ တစ်စက္ကန့်မှာ အရောင်းအဝယ်တွေကို များများထုတ်ဖို့ ကြိုးစားပါတယ်။ ဤတွင် အတိအကျ ရွေးချယ်ရန် တစ်စက္ကန့်လျှင် 311 ဖြစ်သည်။

ဒါပေမယ့် ဘယ်သူကမှ အရှိန်ပြင်းပြင်းနဲ့ မောင်းပြီး အိမ်ပြန်တာ မဟုတ်ဘူး။ ဒါက ရီစရာပါ။ databases တွေနဲ့ အတူတူပါပဲ။ ငါတို့က အရှိန်အပြည့်နဲ့ မောင်းစရာမလိုဘူး၊ ဘယ်သူမှ မစီးဘူး။ 100% CPU ပါ၀င်သော ထုတ်လုပ်မှုတွင် မည်သူမျှ နေထိုင်ခြင်းမရှိပါ။ တစ်စုံတစ်ယောက်အသက်ရှင်နေပေမယ့်လည်း ဒါက မကောင်းပါဘူး။

စိတ်ကူးကတော့ ပုံမှန်အားဖြင့် စွမ်းရည် 20 ရာခိုင်နှုန်းနဲ့ မောင်းနှင်တာ ဖြစ်နိုင်ရင် 50% ထက် မပိုစေရပါဘူး။ ထို့အပြင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ သုံးစွဲသူများအတွက် တုံ့ပြန်မှုအချိန်ကို အကောင်းဆုံးဖြစ်အောင် ကြိုးစားပါသည်။ ဆိုလိုသည်မှာ၊ အခြေအနေအရ 20% အမြန်နှုန်းဖြင့် အနည်းဆုံး latency ရှိနေစေရန် ကျွန်ုပ်တို့၏ခလုတ်များကို လှည့်ရပါမည်။ ဤအရာသည် ကျွန်ုပ်တို့၏စမ်းသပ်မှုများတွင်လည်း အသုံးပြုရန်ကြိုးစားသည့် စိတ်ကူးတစ်ခုဖြစ်သည်။

နောက်ဆုံးအနေနဲ့၊ အကြံပြုချက်များ

• Database Lab ကိုသေချာလုပ်ပါ။
• ဖြစ်နိုင်ရင် ခဏလောက် ပေါက်သွားအောင် လုပ်ပါ - ကစားပြီး လွှင့်ပစ်လိုက်ပါ။ မင်းမှာ တိမ်တွေ ရှိရင် ဒါက ရပ်တည်မှု အများကြီး ရှိတယ် လို့ မပြောဘဲ မနေပါနဲ့။
• စပ်စုပါ။ တစ်ခုခုမှားနေပါက ၎င်းသည် မည်သို့ပြုမူသည်ကို စမ်းသပ်မှုများဖြင့် စစ်ဆေးပါ။ အခြေစိုက်စခန်း၏အလုပ်လုပ်ပုံကိုစစ်ဆေးရန် Nancy ကိုသင်ကိုယ်တိုင်လေ့ကျင့်နိုင်သည်။
• နှင့် အနည်းဆုံး တုံ့ပြန်ချိန်အတွက် ရည်ရွယ်ပါ။
• ပြီးတော့ Postgres အရင်းအမြစ်တွေကို မကြောက်ပါနဲ့။ သတင်းရင်းမြစ်တွေနဲ့ အလုပ်လုပ်တဲ့အခါ အင်္ဂလိပ်လို သိထားရပါမယ်။ အဲဒီမှာ မှတ်ချက်တွေ အများကြီးရှိတယ်၊ အကုန်လုံးကို ရှင်းပြထားတယ်။
• ဒေတာဘေ့စ်၏ကျန်းမာရေးကို အနည်းဆုံးသုံးလတစ်ကြိမ်၊ ကိုယ်တိုင် သို့မဟုတ် Postgres-checkup ပုံမှန်စစ်ဆေးပါ။

မေးခွန်းများကို

ကျေးဇူးအများကြီးတင်ပါတယ်! အလွန်စိတ်ဝင်စားစရာကောင်းသောအရာတစ်ခုဖြစ်သည်။

နှစ်ကျပ်။

ဟုတ်တယ်၊ နှစ်ကျပ်။ ကျွန်တော်သာ နားမလည်ခဲ့ပါ။ နန်စီနဲ့ ကျွန်တော် အလုပ်လုပ်တဲ့အခါ၊ ကန့်သတ်ချက်တစ်ခုပဲ ဒါမှမဟုတ် တစ်ဖွဲ့လုံးကို ညှိနိုင်သလား။

ကျွန်ုပ်တို့တွင် delta config parameter တစ်ခုရှိသည်။ လိုချင်သလောက် တခါတည်း လှည့်လို့ရတယ်။ ဒါပေမယ့် အများကြီး ပြောင်းလဲလိုက်တာနဲ့ မှားယွင်းတဲ့ ကောက်ချက်ဆွဲနိုင်တယ်ဆိုတာ နားလည်ထားဖို့ လိုပါတယ်။

ဟုတ်ကဲ့။ ငါဘာလို့မေးတာလဲ။ သင့်တွင် ကန့်သတ်ချက်တစ်ခုသာရှိသည့်အခါ စမ်းသပ်မှုများပြုလုပ်ရန် ခက်ခဲသောကြောင့်ဖြစ်သည်။ အဲဒါကို တင်းတင်းကျပ်ကျပ်လုပ်တယ်၊ ဘယ်လိုအလုပ်လုပ်တယ်ဆိုတာ ကြည့်ပါ။ ကျွန်တော် သူ့ကို ထုတ်လိုက်တယ်။ ထို့နောက်သင်နောက်တစ်ခုစတင်ပါ။

တစ်ချိန်တည်းမှာ တင်းကျပ်နိုင်ပေမယ့် အခြေအနေပေါ်မူတည်ပါတယ်။ ဒါပေမယ့် အကြံဥာဏ်တစ်ခုကို စမ်းသပ်တာက ပိုကောင်းပါတယ်။ မနေ့က အကြံတစ်ခုရခဲ့တယ်။ ကျွန်တော်တို့ အရမ်းနီးစပ်တဲ့ အခြေအနေတစ်ခုရှိခဲ့ပါတယ်။ ပုံစံနှစ်မျိုးရှိခဲ့သည်။ ပြီးတော့ ဘာကြောင့် ကြီးကြီးမားမား ကွာခြားမှု ရှိတယ်ဆိုတာ ကျွန်တော်တို့ နားမလည်နိုင်ဘူး။ ပြီးတော့ ခြားနားချက်ကို တစိုက်မတ်မတ် နားလည်ပြီး ရှာဖွေနိုင်ဖို့ dichotomy ကို သုံးဖို့ လိုတယ်ဆိုတဲ့ အတွေးပေါ်လာတယ်။ ကန့်သတ်ဘောင်များ၏ တစ်ဝက်ကို တူညီပြီး လေးပုံတစ်ပုံ၊ စသည်တို့ကို သင်ချက်ချင်းပြုလုပ်နိုင်သည်။ အရာအားလုံးသည် ပြောင်းလွယ်ပြင်လွယ်ဖြစ်သည်။

ပြီးတော့ နောက်ထပ်မေးခွန်းတစ်ခုရှိသေးတယ်။ ပရောဂျက်သည် ငယ်ရွယ်ပြီး ဖွံ့ဖြိုးဆဲဖြစ်သည်။ စာရွက်စာတမ်း အဆင်သင့်ဖြစ်နေပါပြီ၊ အသေးစိတ်ဖော်ပြချက် ရှိပါသလား။

ကန့်သတ်ချက်များ၏ဖော်ပြချက်အား ထိုနေရာတွင် အထူးလင့်ခ်တစ်ခု ပြုလုပ်ထားသည်။ အဲဒီမှာ။ ဒါပေမယ့် တော်တော်များများတော့ မရောက်သေးပါဘူး။ စိတ်တူကိုယ်တူ လူတွေကို ရှာနေတယ်။ ပြီးတော့ ငါဖျော်ဖြေတဲ့အခါ သူတို့ကိုတွေ့တယ်။ ဒါက အရမ်းမိုက်တယ်။ တစ်စုံတစ်ယောက်သည် ကျွန်ုပ်နှင့် လက်တွဲလုပ်ဆောင်နေပြီဖြစ်ပြီး၊ တစ်စုံတစ်ဦးသည် ထိုနေရာတွင် ကူညီပြီး တစ်ခုခုလုပ်ခဲ့သည်။ ပြီးတော့ ဒီအကြောင်းအရာကို စိတ်ဝင်စားတယ်ဆိုရင် လွဲမှားနေတဲ့အရာတွေကို အကြံပြုချက်ပေးပါ။

ဓာတ်ခွဲခန်း ဆောက်ပြီးတာနဲ့ တုံ့ပြန်ချက် ထွက်လာပါလိမ့်မယ်။ ကြည့်ကျတာပေါ့။ ကျေးဇူးတင်ပါသည်!

မင်္ဂလာပါ! အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ Amazon ရဲ့ ပံ့ပိုးမှု ရှိတယ်လို့ မြင်တယ်။ GSP ထောက်ပံ့ရန် အစီအစဉ်ရှိပါသလား။

မေးခွန်းကောင်း။ အဲဒါကို ကျနော်တို့ စလုပ်တယ်။ ပြီးတော့ ကျွန်တော်တို့က ပိုက်ဆံစုချင်တာကြောင့် အခုလောလောဆယ် သိမ်းထားတယ်။ ဆိုလိုသည်မှာ၊ localhost တွင် run ကိုအသုံးပြုခြင်းထောက်ခံမှုရှိသည်။ သင်ကိုယ်တိုင် စံနမူနာတစ်ခု ဖန်တီးပြီး ပြည်တွင်း၌ အလုပ်လုပ်နိုင်သည်။ စကားမစပ်၊ ဒါပဲလုပ်တယ်။ ဒါကို GSP မှာ Getlab မှာလုပ်တယ်။ ဒါပေမယ့် Google မှာ စျေးပေါတဲ့ နေရာတွေ မရှိသေးတာကြောင့် ဒီလိုမျိုး စည်းရုံးမှုမျိုး လုပ်ရတာကို ကျွန်တော်တို့ မမြင်မိသေးပါဘူး။ ရှိသည် ??? သာဓကများရှိသော်လည်း ၎င်းတို့တွင် ကန့်သတ်ချက်များရှိသည်။ ပထမဦးစွာ၊ ၎င်းတို့သည် 70% လျှော့စျေးသာအမြဲရှိပြီးသင်ထိုနေရာတွင်စျေးနှုန်းဖြင့်ကစားနိုင်သည်။ အစက်အပြောက်များတွင်၊ သင်ကန်ခံရမည့်ဖြစ်နိုင်ခြေကို လျှော့ချရန်အတွက် ကျွန်ုပ်တို့သည် စျေးနှုန်းကို 5-10% တိုးပေးပါသည်။ ဆိုလိုသည်မှာ သင်သည် အစက်အပြောက်များကို သိမ်းဆည်းထားသော်လည်း ၎င်းတို့ကို အချိန်မရွေး သင့်ထံမှ ဖယ်ထုတ်နိုင်သည်။ သူများတွေထက် နည်းနည်းပိုမြင့်ရင် နောက်မှ သတ်ခံရလိမ့်မယ်။ Google တွင် လုံးဝကွဲပြားသော တိကျမှုများရှိသည်။ နောက်တစ်ခုက အလွန်ဆိုးရွားတဲ့ ကန့်သတ်ချက်တစ်ခုရှိတယ် - သူတို့က 24 နာရီပဲ အသက်ရှင်တယ်။ တစ်ခါတစ်ရံတွင် ကျွန်ုပ်တို့သည် စမ်းသပ်မှုတစ်ခုကို ၅ ရက်ကြာ ပြုလုပ်လိုပါသည်။ ဒါပေမယ့် အစက်အပြောက်တွေမှာ သင်လုပ်နိုင်တယ်၊ အစက်အပြောက်တွေဟာ တစ်ခါတစ်ရံ လနဲ့ချီကြာတတ်ပါတယ်။

မင်္ဂလာပါ! အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ စစ်ဆေးမှုကို သင်ဖော်ပြခဲ့သည်။ stat_statements အမှားများကို သင်မည်ကဲ့သို့ တွက်ချက်သနည်း။

အရမ်းကောင်းတဲ့မေးခွန်းပါ။ အသေးစိပ်ပြပြီး ပြောပြနိုင်ပါတယ်။ အတိုချုပ်အားဖြင့်၊ တောင်းဆိုမှုအဖွဲ့များ မည်ကဲ့သို့ မျှောချလာသည်ကို ကြည့်သည်၊ မည်မျှ ပြုတ်ကျပြီး အသစ်မည်မျှ ပေါ်လာသည်ကို ကြည့်ပါသည်။ ထို့နောက် ကျွန်ုပ်တို့သည် မက်ထရစ်နှစ်ခု- စုစုပေါင်း_အချိန်နှင့် ခေါ်ဆိုမှုများကို ကြည့်ရှုသည်၊ ထို့ကြောင့် အမှားနှစ်ခုရှိသည်။ ပြီးတော့ ရေပေါ်အဖွဲ့တွေရဲ့ အလှူငွေကိုလည်း ကြည့်တယ်။ ထွက်ခွာသွားသူများနှင့် ရောက်ရှိလာသူများဟူ၍ အုပ်စုခွဲနှစ်ခုရှိသည်။ ပုံတစ်ခုလုံးအတွက် သူတို့ရဲ့ ပံ့ပိုးကူညီမှုက ဘာတွေလဲဆိုတာ ကြည့်လိုက်ရအောင်။

လျှပ်တစ်ပြက်များကြားတွင် နှစ်ကြိမ် သို့မဟုတ် သုံးကြိမ် လှည့်လာမည်ကို သင် မကြောက်ဘူးလား။

အဲဒါက သူတို့ပြန်ပြီး မှတ်ပုံတင်ခဲ့တာလား ဒါမှမဟုတ် ဘာလဲ။

ဥပမာအားဖြင့်၊ ဤတောင်းဆိုချက်သည် တစ်ကြိမ်ကြိုတင်ကြိုတင်ပြင်ဆင်ထားပြီး၊ ထို့နောက်ရောက်လာပြီး နောက်တစ်ကြိမ်ကြိုတင်ကြိုတင်မှာထားကာ၊ နောက်တစ်ကြိမ်ထပ်လာကာ ထပ်မံကြိုတင်ပြင်ဆင်ထားသည်။ ပြီးတော့ မင်းဒီမှာ တစ်ခုခုကို တွက်ချက်ပြီး အားလုံးဘယ်မှာလဲ။

ကောင်းတဲ့မေးခွန်းကို ကြည့်ရပါလိမ့်မယ်။

ကျွန်တော်လည်း အလားတူလုပ်ခဲ့တယ်။ ပိုရိုးရှင်းတယ်၊ ငါတစ်ယောက်တည်းလုပ်တယ်။ သို့သော် ကျွန်ုပ်သည် ပြန်လည်သတ်မှတ်ရန်၊ stat_statements များကို ပြန်လည်သတ်မှတ်ပြီး အချို့အပိုင်းများထက်နည်းကြောင်း လျှပ်တစ်ပြက်ရိုက်ချက်တွင် တွက်ချက်ရမည်ဖြစ်ပြီး ၎င်းတွင် stat_statements မည်မျှစုပုံနိုင်သည်၏ မျက်နှာကြက်သို့ မရောက်ရှိသေးပါ။ ပြီးတော့ ကျွန်မနားလည်တာကတော့ အများစုကတော့ ဘာမှ ရွှေ့ပြောင်းခြင်း မရှိပါဘူး။

ဟုတ်ကဲ့ဟုတ်ကဲ့။

ဒါပေမယ့် စိတ်ချယုံကြည်စွာ ဘယ်လိုလုပ်ရမလဲဆိုတာတော့ မသိဘူး။

ကံမကောင်းစွာဖြင့်၊ ကျွန်ုပ်တို့သည် ထိုနေရာတွင် မေးမြန်းချက်စာသားကို အသုံးပြုခြင်းရှိမရှိ သို့မဟုတ် pg_stat_statements ဖြင့် queryid နှင့် ၎င်းကိုအာရုံစိုက်ခြင်းရှိမရှိ အတိအကျမမှတ်မိပါ။ အကယ်၍ ကျွန်ုပ်တို့သည် queryid ကိုအာရုံစိုက်ပါက၊ သီအိုရီအရ ကျွန်ုပ်တို့သည် နှိုင်းယှဉ်နိုင်သော အရာများကို နှိုင်းယှဉ်နေပါသည်။

မဟုတ်ပါ၊ လျှပ်တစ်ပြက်ရိုက်ချက်များကြားတွင် အကြိမ်ပေါင်းများစွာ တွန်းထုတ်နိုင်ပြီး နောက်တစ်ကြိမ် ထပ်လာနိုင်သည်။

တူညီသော ID ဖြင့်?

ဟုတ်ပါတယ်။

ဒါကို လေ့လာမယ်။ မေးခွန်းကောင်း။ အဲဒါကို လေ့လာဖို့လိုတယ်။ ဒါပေမယ့် အခုမြင်တွေ့နေရတာက 0 လို့ရေးထားတယ်...

ဒါက ရှားရှားပါးပါး ကိစ္စပဲ၊ ဒါပေမယ့် stat_statemetns တွေက အဲဒီနေရာကို ရွှေ့ပြောင်းနိုင်တယ်ဆိုတာ သိလိုက်ရတော့ အံ့သြသွားတယ်။

Pg_stat_statements တွင် အရာများစွာ ရှိနိုင်ပါသည်။ သင့်တွင် track_utility = ဖွင့်ထားပါက၊ သင်၏အစုံများကို ခြေရာခံမိသည်ဟူသောအချက်ကို ကျွန်ုပ်တို့တွေ့လာရသည်။

ဟုတ်ပါတယ်, သင်တန်း၏။

အကယ်၍ သင့်တွင် ကျပန်းဖြစ်သည့် java hibernate ရှိပါက hash table သည် ထိုနေရာတွင် ရှိနေမည်ဖြစ်သည်။ အလွန်တင်ထားသော application ကိုပိတ်လိုက်သည်နှင့်သင်အုပ်စု 50-100 နှင့်အဆုံးသတ်သည်။ ပြီးတော့ အရာအားလုံးက အနည်းနဲ့အများ တည်ငြိမ်နေမှာပေါ့။ ၎င်းကို တိုက်ဖျက်ရန် နည်းလမ်းတစ်ခုမှာ pg_stat_statements.max ကို တိုးမြှင့်ရန် ဖြစ်သည်။

ဟုတ်တယ်၊ ဒါပေမယ့် မင်းဘယ်လောက်သိထားရမယ်။ ပြီးတော့ သူ့ကို တစ်နည်းနည်းနဲ့ စောင့်ကြည့်ရမယ်။ အဲဒါ ငါလုပ်တယ်။ ဆိုလိုသည်မှာ ကျွန်ုပ်တွင် pg_stat_statements.max ရှိသည်။ လျှပ်တစ်ပြက်ရိုက်တဲ့အချိန်မှာ 70% မရောက်သေးဘူးလို့ မြင်တယ်။ ကောင်းပြီ၊ ငါတို့ ဘာမှ မဆုံးရှုံးသေးဘူး။ ပြန်လည်သတ်မှတ်ကြပါစို့။ ပြီးတော့ ငါတို့ ထပ်ပြီး ကယ်တင်တယ်။ နောက်လျှပ်တစ်ပြက်ရိုက်ချက် 70 ထက်နည်းပါက၊ သင်နောက်တဖန်ဘာမှမဆုံးရှုံးတော့ပါ။

ဟုတ်ကဲ့။ ပုံသေသည် ယခု 5 ဖြစ်သည်။ ၎င်းသည် လူများစွာအတွက် လုံလောက်ပါသည်။

အများအားဖြင့်တော့ ဟုတ်ပါတယ်။

ဗီဒီယိုများ:

PS ကျွန်ုပ်၏ကိုယ်စား၊ Postgres တွင် လျှို့ဝှက်အချက်အလက်များပါဝင်ပြီး ၎င်းကိုစမ်းသပ်မှုပတ်ဝန်းကျင်တွင်မထည့်သွင်းနိုင်ပါက သင်အသုံးပြုနိုင်ပါသည် PostgreSQL အမည်မသိသူ. အစီအစဥ်သည် ခန့်မှန်းခြေအားဖြင့် အောက်ပါအတိုင်းဖြစ်သည်။

source: www.habr.com