PostgreSQL စောင့်ကြည့်ခြင်း၏အခြေခံများ။ Alexey Lesovsky

Data Egret “PostgreSQL စောင့်ကြည့်ရေးအခြေခံများ” မှ Alexey Lesovsky ၏ အစီရင်ခံစာကို ဖတ်ရန် အကြံပြုလိုပါသည်။

ဤအစီရင်ခံစာတွင်၊ Alexey Lesovsky သည် post-gress ကိန်းဂဏန်းများ၏ အဓိကအချက်များ၊ ၎င်းတို့သည် အဘယ်အရာကိုဆိုလိုသနည်း၊ အဘယ်ကြောင့် ၎င်းတို့သည် စောင့်ကြည့်လေ့လာခြင်းတွင် ရှိနေသင့်သည်ကို ဆွေးနွေးမည်ဖြစ်သည်။ စောင့်ကြည့်ရေးတွင် မည်သည့်ဂရပ်များ ရှိသင့်သည်၊ ၎င်းတို့ကို ထည့်သွင်းနည်းနှင့် ၎င်းတို့ကို အဓိပ္ပာယ်ဖွင့်ဆိုပုံအကြောင်း။ အစီရင်ခံစာသည် ဒေတာဘေ့စ်စီမံခန့်ခွဲသူများ၊ စနစ်စီမံခန့်ခွဲသူများနှင့် Postgres ပြဿနာဖြေရှင်းခြင်းအား စိတ်ဝင်စားသော developer များအတွက် အသုံးဝင်မည်ဖြစ်သည်။

ကျွန်တော့်နာမည်က Alexey Lesovsky ဖြစ်ပြီး Data Egret ကုမ္ပဏီကို ကိုယ်စားပြုပါတယ်။

ကိုယ်နဲ့ပတ်သက်တဲ့ စကားတချို့။ ကျွန်တော်ဟာ System Administrator အဖြစ်နဲ့ စတင်ခဲ့တာ ကြာပါပြီ။

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

ပြီးတော့ ကျွန်တော့်ရဲ့အသက်မွေးဝမ်းကြောင်းတစ်လျှောက်လုံးမှာ စာရင်းဇယားတွေ၊ စောင့်ကြည့်လေ့လာရေးနဲ့ တယ်လီမီတာဆိုင်ရာ အကြောင်းအရာတွေကို အမြဲစိတ်ဝင်စားခဲ့ပါတယ်။ ငါစနစ်စီမံခန့်ခွဲသူဖြစ်သောအခါ Zabbix နှင့်အလွန်နီးကပ်စွာအလုပ်လုပ်ခဲ့သည်။ ပြီးတော့ ဇာတ်ညွှန်းလေးတွေ ရေးတယ်။ zabbix-extension များ. သူ့ခေတ်က တော်တော်နာမည်ကြီးတယ်။ Linux တွင်သာမက အစိတ်အပိုင်းများစွာပါသော ကွဲပြားခြားနားသော အရေးကြီးသောအရာများကို စောင့်ကြည့်နိုင်မည်ဖြစ်သည်။

အခု ကျွန်တော် PostgreSQL မှာ အလုပ်လုပ်နေပါတယ်။ PostgreSQL ကိန်းဂဏန်းအချက်အလက်တွေနဲ့ အလုပ်လုပ်နိုင်စေမယ့် နောက်ထပ်အရာတစ်ခုကို ကျွန်တော်ရေးထားပြီးသားပါ။ အဲ့ဒါကိုခေါ်တယ် pgCenter (Habre ၏ဆောင်းပါး - အာရုံကြောများနှင့် တင်းမာမှုမရှိဘဲ လွန်ခဲ့သည့် စာရင်းဇယားများ).

နိဒါန်းလေးတစ်ခု။ ကျွန်ုပ်တို့၏ဖောက်သည်များ၊ ကျွန်ုပ်တို့၏ဖောက်သည်များသည် အဘယ်အခြေအနေမျိုးရှိသနည်း။ ဒေတာဘေ့စ်နှင့် ပတ်သက်သော မတော်တဆမှုမျိုး ရှိသည်။ ဒေတာဘေ့စ်ကို ပြန်လည်ရယူပြီးသောအခါ ဌာနအကြီးအကဲ သို့မဟုတ် ဖွံ့ဖြိုးတိုးတက်ရေးဌာနအကြီးအကဲက “မိတ်ဆွေတို့၊ ဒေတာဘေ့စ်ကို စောင့်ကြည့်ဖို့ လိုပါတယ်၊ ဘာဖြစ်လို့လဲဆိုတော့ ဆိုးရွားတဲ့ တစ်ခုခုဖြစ်ခဲ့လို့ အနာဂတ်မှာ ဒီလိုမဖြစ်အောင် တားဆီးဖို့လိုတယ်။” ပြီးတော့ သင့်ဒေတာဘေ့စ် - PostgreSQL၊ MySQL သို့မဟုတ် အခြားအချို့သော အခြားအရာများကို စောင့်ကြည့်နိုင်စေရန်အတွက် စောင့်ကြည့်ရေးစနစ်တစ်ခုကို ရွေးချယ်ခြင်း သို့မဟုတ် လက်ရှိစောင့်ကြည့်ရေးစနစ်ကို လိုက်လျောညီထွေဖြစ်အောင် ပြုလုပ်ခြင်း၏ စိတ်ဝင်စားဖွယ်လုပ်ငန်းစဉ်ကို ဤနေရာတွင် စတင်ပါသည်။ ပြီးတော့ လုပ်ဖော်ကိုင်ဖက်တွေက “ဒီလိုမျိုး ဒေတာဘေ့စ်တစ်ခုရှိတယ်ဆိုတာ ငါကြားတယ်။ သုံးကြည့်ရအောင်။" လုပ်ဖော်ကိုင်ဖက်များ အချင်းချင်း ငြင်းခုံမှုများ စတင်လာသည်။ အဆုံးတွင် ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်တစ်မျိုးမျိုးကို ရွေးချယ်ထားကြောင်း ပေါ်လွင်လာသော်လည်း PostgreSQL စောင့်ကြည့်စစ်ဆေးခြင်းကို ၎င်းတွင် ညံ့ဖျင်းစွာတင်ပြထားပြီး တစ်ခုခုကို အမြဲထည့်ရမည်ဖြစ်သည်။ GitHub မှ အချို့သော repositories ကိုယူပါ၊ ၎င်းတို့ကို ပုံတူကူးရန်၊ scripts များကို လိုက်လျောညီထွေဖြစ်အောင်၊ တစ်နည်းနည်းဖြင့် စိတ်ကြိုက်ပြင်ဆင်ပါ။ နောက်ဆုံးတွင် ၎င်းသည် ကိုယ်တိုင်လုပ်ဆောင်မှု တစ်မျိုးမျိုးဖြင့် အဆုံးသတ်သည်။

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် တောင်းဆိုချက်အားလုံး၏ စုစုပေါင်းလုပ်ဆောင်ချိန်ကို ယူနိုင်ပြီး အထက်အကွက်များကို အသုံးပြု၍ တောင်းဆိုချက်အရေအတွက်ဖြင့် ပိုင်းခြားနိုင်သည်ဟူသောအချက်မှ စတင်နိုင်သည်။ ဒါပေမယ့် ဒါက ဆေးရုံရဲ့ ပျမ်းမျှအပူချိန်ပါ။ ကျွန်ုပ်တို့သည် အခြားနယ်ပယ်များမှ စတင်နိုင်သည် - အနိမ့်ဆုံး မေးမြန်းမှုလုပ်ဆောင်ချိန်၊ အများဆုံးနှင့် ပျမ်းမျှ။ ကျွန်ုပ်တို့သည် ရာခိုင်နှုန်းများကိုပင် တည်ဆောက်နိုင်သည်၊ PostgreSQL သည် ၎င်းအတွက် သက်ဆိုင်သည့် လုပ်ဆောင်ချက်များ ရှိသည်။ ပြီးပြည့်စုံသောတောင်းဆိုမှုများအတွက် ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်၏တုံ့ပြန်ချိန်ကိုဖော်ပြသည့်နံပါတ်အချို့ကိုကျွန်ုပ်တို့ရရှိနိုင်ပါသည်၊ ဆိုလိုသည်မှာကျွန်ုပ်တို့သည်တောင်းဆိုချက်အတု 'select 1' ကိုလုပ်ဆောင်ပြီးတုံ့ပြန်ချိန်ကိုကြည့်ရှုခြင်းမရှိပါ၊ သို့သော်ပြီးသောတောင်းဆိုမှုများအတွက်တုံ့ပြန်ချိန်ကိုခွဲခြမ်းစိတ်ဖြာပြီးဆွဲပါ။ သီးခြားကိန်းဂဏန်းတစ်ခုဖြစ်စေ၊ ကျွန်ုပ်တို့သည် ၎င်းကိုအခြေခံ၍ ဂရပ်တစ်ခုတည်ဆောက်ပါ။

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

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

အရောင်းအ၀ယ်အရေအတွက်ကို ခန့်မှန်းရန်အတွက်၊ ကျွန်ုပ်တို့သည် pg_stat_database မြင်ကွင်းကို ထပ်မံကိုးကားနိုင်ပါသည်။ commits အရေအတွက်နှင့် rollbacks အရေအတွက်တို့ကို ပေါင်းထည့်နိုင်ပြီး တစ်စက္ကန့်လျှင် ငွေပေးငွေယူအရေအတွက်ကို ရယူနိုင်ပါသည်။

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

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

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

ဤမက်ထရစ်များထဲမှ တစ်ခုသည် အလုပ်ချိန်ဖြစ်သည်။ သို့သော် PostgreSQL ရှိ အလုပ်ချိန်သည် အနည်းငယ် ဆန်းကျယ်သည်။ ဘာကြောင့်လဲဆိုတာ ပြောပြမယ်။ PostgreSQL စတင်သောအခါ၊ အလုပ်ချိန်သည် စတင်သည်။ ဥပမာအားဖြင့်၊ အချို့သောအလုပ်သည် ညအချိန်တွင် လုပ်ဆောင်နေပါက၊ OOM-လူသတ်သမားသည် ရောက်ရှိလာပြီး PostgreSQL ကလေးလုပ်ငန်းစဉ်ကို အတင်းအကျပ်ရပ်စဲလိုက်လျှင် ဤအခြေအနေတွင် PostgreSQL သည် client များအားလုံး၏ချိတ်ဆက်မှုကို ရပ်ဆိုင်းလိုက်ကာ sharded memory area ကို ပြန်လည်သတ်မှတ်ပြီး ပြန်လည်ရယူခြင်းမှ စတင်သည်။ နောက်ဆုံးစစ်ဆေးရေးဂိတ်။ စစ်ဆေးရေးဂိတ်မှ ဤပြန်လည်ရယူခြင်းသည် ကြာရှည်နေသော်လည်း ဒေတာဘေ့စ်သည် ချိတ်ဆက်မှုများကို လက်မခံပါ၊ ဆိုလိုသည်မှာ ဤအခြေအနေကို စက်ရပ်ချိန်အဖြစ် အကဲဖြတ်နိုင်ပါသည်။ သို့သော် အလုပ်ချိန်ကောင်တာအား ပြန်လည်သတ်မှတ်မည်မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် ပထမအခိုက်အတန့်မှ စာတိုက်မာစတာစတင်သည့်အချိန်ကို ထည့်သွင်းစဉ်းစားသောကြောင့်ဖြစ်သည်။ ထို့ကြောင့် ထိုသို့သော အခြေအနေများကို ကျော်လွှားနိုင်သည်။

ဖုန်စုပ်စက် လုပ်သားအရေအတွက်ကိုလည်း စောင့်ကြည့်သင့်သည်။ PostgreSQL တွင် autovacuum ဟူသည်ကို လူတိုင်းသိပါသလား။ ၎င်းသည် PostgreSQL ရှိ စိတ်ဝင်စားဖွယ်ကောင်းသော စနစ်ခွဲတစ်ခုဖြစ်သည်။ သူ့အကြောင်း ဆောင်းပါးတွေ အများကြီးရေးပြီး အစီရင်ခံစာတွေ အများကြီး လုပ်ထားတယ်။ လေဟာနယ်နဲ့ ဘယ်လိုအလုပ်လုပ်သင့်တယ်ဆိုတာ ဆွေးနွေးမှုတွေ အများကြီးရှိပါတယ်။ တော်တော်များများက အဲဒါကို မကောင်းမှုလို့ ယူဆကြတယ်။ ဒါပေမယ့် အဲဒါက ဘယ်လိုလဲ။ ၎င်းသည် အရောင်းအ၀ယ်ပြုလုပ်ရာတွင် မလိုအပ်သော ခေတ်မမီသော အတန်းများ၏ ဗားရှင်းများကို ရှင်းပေးကာ အတန်းအသစ်အတွက် ဇယားများနှင့် အညွှန်းများတွင် နေရာလွတ်များ အခမဲ့ပေးသည့် အမှိုက်စုဆောင်းသူ၏ analogue အမျိုးအစားတစ်ခုဖြစ်သည်။

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

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

PostgreSQL ၏နောက်ထပ်အချက်တစ်ခုမှာ PostgreSQL သည်ရှည်လျားသောအရောင်းအ ၀ ယ်များအတွက်အလွန်စိတ်မကောင်းဖြစ်နေသည်။ အထူးသဖြင့် အချိန်အကြာကြီး ဝိုင်းပြီး ဘာမှမလုပ်တဲ့ အရောင်းအဝယ်တွေကနေပေါ့။ ၎င်းကို stat idle-in-transaction ဟုခေါ်သည်။ ထိုသို့သော ငွေပေးငွေယူသည် သော့ခတ်ထားပြီး လေဟာနယ်ကို အလုပ်မလုပ်အောင် တားဆီးပေးသည်။ ရလဒ်အနေဖြင့် စားပွဲများသည် ဖောင်းလာပြီး အရွယ်အစား တိုးလာသည်။ ပြီးတော့ ဒီဇယားတွေနဲ့ အလုပ်လုပ်တဲ့ queries တွေက ပိုနှေးကွေးလာတယ်၊ ဘာကြောင့်လဲဆိုတော့ အတန်းရဲ့ ဗားရှင်းအဟောင်းတွေကို memory ကနေ disk နဲ့ back တွေကို တွန်းထုတ်ဖို့ လိုအပ်တာကြောင့်ပါ။ ထို့ကြောင့် အချိန်၊ အကြာဆုံး အရောင်းအ၀ယ်ပြုလုပ်သည့်ကြာချိန်၊ အရှည်ဆုံး လေဟာနယ်တောင်းဆိုမှုများကိုလည်း စောင့်ကြည့်ရန် လိုအပ်ပါသည်။ OLTP load တစ်ခုအတွက် 10-20-30 မိနစ်ကျော်ကြာမြင့်နေပြီဖြစ်သော လုပ်ငန်းစဉ်အချို့ကိုကျွန်ုပ်တို့တွေ့မြင်ပါက၊ ၎င်းတို့ကိုအာရုံစိုက်ပြီး ၎င်းတို့အား အတင်းအကြပ်ပိတ်ပစ်ရန် လိုအပ်ပါသည် သို့မဟုတ် ၎င်းတို့အတွက် အက်ပ်ကို အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ရန် လိုအပ်ပါသည်။ အကြာကြီးမခေါ်ပါနဲ့ ။ ခွဲခြမ်းစိတ်ဖြာမှုတစ်ခုအတွက်၊ 10-20-30 မိနစ်သည် ပုံမှန်ဖြစ်ပြီး ပိုရှည်သည်များလည်းရှိသည်။

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

PostgreSQL ရှုထောင့်မှ ဖောက်သည်များသည် မတူညီသောကြောင့် ချိတ်ဆက်ထားသော client များအကြောင်း အချက်အလက်သည် အရေးကြီးပါသည်။ ဖောက်သည်ကောင်းတွေရှိသလို မကောင်းတဲ့ဖောက်သည်တွေလည်း ရှိတယ်။

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

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

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

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

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

ထို့ကြောင့်၊ ဤအချက်အလက်ကို စောင့်ကြည့်ခြင်းတွင် ထည့်သွင်းရန်၊ သင်သည် pg_stat_activity စနစ်မြင်ကွင်းကို ဝင်ရောက်ကြည့်ရှုရန် လိုအပ်သည်။ အကယ်၍ သင်သည် PostgreSQL တွင် အချိန်များစွာဖြုန်းပါက၊ ၎င်းသည် PostgreSQL တွင် လက်ရှိလုပ်ဆောင်ချက်ကို ပြသသောကြောင့် ၎င်းသည် သင့်သူငယ်ချင်းဖြစ်လာရန် အလွန်ကောင်းသော မြင်ကွင်းတစ်ခုဖြစ်သည်။ လုပ်ငန်းစဉ်တစ်ခုစီအတွက် ဤလုပ်ငန်းစဉ်နှင့်ပတ်သက်သည့် အချက်အလက်များကို ဖော်ပြသည့် သီးခြားစာကြောင်းတစ်ခု ရှိသည်- မည်သည့် host ချိတ်ဆက်မှုမှ ပြုလုပ်ခဲ့ကြောင်း၊ မည်သည့်အသုံးပြုသူအောက်တွင်၊ မည်သည့်အမည်အောက်တွင်၊ ငွေပေးငွေယူစတင်ချိန်၊ လက်ရှိလုပ်ဆောင်နေသည့် တောင်းဆိုချက်၊ မည်သည့်တောင်းဆိုချက်ကို နောက်ဆုံးလုပ်ဆောင်ခဲ့သည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် stat အကွက်ကို အသုံးပြု၍ သုံးစွဲသူ၏အခြေအနေကို အကဲဖြတ်နိုင်ပါသည်။ နှိုင်းရပြောရလျှင်၊ ကျွန်ုပ်တို့သည် ဤအကွက်ဖြင့် အုပ်စုဖွဲ့နိုင်ပြီး ဒေတာဘေ့စ်တွင် လက်ရှိရှိသည့် ကိန်းဂဏာန်းများနှင့် ဒေတာဘေ့စ်တွင် ဤကိန်းဂဏာန်းပါသော ချိတ်ဆက်မှုအရေအတွက်တို့ကို ရယူနိုင်သည်။ ပြီးတော့ ရရှိပြီးသား နံပါတ်တွေကို ကျွန်ုပ်တို့ရဲ့ စောင့်ကြည့်လေ့လာရေးထံ ပေးပို့နိုင်ပြီး ၎င်းတို့ကို အခြေခံ၍ ဂရပ်များကို ရေးဆွဲနိုင်ပါတယ်။
ငွေပေးငွေယူ၏ကြာချိန်ကို အကဲဖြတ်ရန်လည်း အရေးကြီးပါသည်။ လေဟာနယ်၏ကြာချိန်ကို အကဲဖြတ်ရန် အရေးကြီးသည်ဟု ကျွန်ုပ်ပြောထားပြီးဖြစ်သော်လည်း အရောင်းအ၀ယ်များကို တူညီသောနည်းဖြင့် အကဲဖြတ်ပါသည်။ xact_start နှင့် query_start အကွက်များ ရှိပါသည်။ ပြောရလျှင် ၎င်းတို့သည် ငွေပေးငွေယူ၏ စတင်ချိန်နှင့် တောင်းဆိုချက်၏ စတင်ချိန်ကို ပြသသည်။ ကျွန်ုပ်တို့သည် လက်ရှိအချိန်တံဆိပ်ကိုပြသပြီး ငွေပေးငွေယူကို နုတ်ပြီး အချိန်တံဆိပ်ကို တောင်းဆိုသည့် now() လုပ်ဆောင်ချက်ကို ရယူပါသည်။ ကျွန်ုပ်တို့သည် ငွေပေးငွေယူကြာချိန်၊ တောင်းဆိုချက်၏ကြာချိန်ကို ရရှိပါသည်။

ရှည်လျားသော အရောင်းအဝယ်များကို မြင်ပါက၊ ၎င်းတို့ကို ပြီးအောင် လုပ်ဆောင်သင့်သည်။ OLTP load တစ်ခုအတွက်၊ ရှည်လျားသော ငွေပေးငွေယူများသည် 1-2-3 မိနစ်ထက် ပိုနေပြီဖြစ်သည်။. OLAP လုပ်ငန်းတာဝန်အတွက်၊ ရှည်လျားသော ငွေပေးငွေယူများသည် ပုံမှန်ဖြစ်သော်လည်း ပြီးမြောက်ရန် နှစ်နာရီထက် ပိုကြာပါက၊ ၎င်းသည် တစ်နေရာရာတွင် လွဲချော်နေသည့် လက္ခဏာတစ်ခုလည်း ဖြစ်သည်။

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

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

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

"floating" စာရင်းအင်းများတွင် ကွဲလွဲချက်များကိုလည်း ရှာဖွေနိုင်သည်။ ဘာကိုဆိုလိုတာလဲ? PostgreSQL တွင် အလွန်အားကောင်းပြီး အလွန်ကောင်းမွန်သော query planner တစ်ခုရှိသည်။ နှင့် developer များသည်၎င်း၏ဖွံ့ဖြိုးတိုးတက်မှုအတွက်အချိန်များစွာကိုမြှုပ်နှံထားသည်။ သူဘယ်လိုအလုပ်လုပ်သလဲ။ ကောင်းမွန်သောအစီအစဥ်များပြုလုပ်ရန်အတွက် PostgreSQL သည် အချိန်ကာလတစ်ခုနှင့်တစ်ခုကြားကာလတွင် ဇယားများအတွင်း ဒေတာဖြန့်ဝေမှုဆိုင်ရာ စာရင်းအင်းများကို စုဆောင်းပါသည်။ ဤအရာများသည် အသုံးအများဆုံးတန်ဖိုးများဖြစ်သည်- တစ်မူထူးခြားသောတန်ဖိုးများ ၊ ဇယားရှိ NULL ဆိုင်ရာအချက်အလက်များ၊ အချက်အလက်အများအပြား။

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

စာရင်းအင်းများ “float” ဖြစ်သွားသည်။ အရည်အသွေးနှင့် ပမာဏဒေတာသည် ဇယားတွင် တစ်နည်းနည်းဖြင့် ပြောင်းလဲသွားသော်လည်း စာရင်းဇယားများကို ကောက်ယူခြင်းမရှိပါ။ ပြီးတော့ ဖွဲ့ထားတဲ့ အစီအစဥ်တွေက အသင့်တော်ဆုံးဖြစ်မှာမဟုတ်ဘူး။ ဇယားများကိုအခြေခံ၍ ကျွန်ုပ်တို့၏အစီအစဉ်များသည် စုဆောင်းထားသောစောင့်ကြည့်မှုအပေါ်အခြေခံ၍ အသင့်တော်ဆုံးဖြစ်မည်ဆိုပါက၊ ဤကွဲလွဲချက်များကို ကျွန်ုပ်တို့တွေ့မြင်နိုင်မည်ဖြစ်ပါသည်။ ဥပမာအားဖြင့်၊ တစ်နေရာရာတွင် ဒေတာသည် အရည်အသွေးအရ ပြောင်းလဲသွားပြီး အညွှန်းအစား၊ ဇယားမှတဆင့် ဆင့်ကဲဖြတ်သန်းမှုကို စတင်အသုံးပြုခဲ့သည်၊ ဆိုလိုသည်မှာ၊ အကယ်၍ query တစ်ခုသည် အတန်း 100 သာပြန်ရန်လိုအပ်ပါက (100 ကန့်သတ်ချက်ရှိသည်)၊ ထို့နောက် ဤမေးခွန်းအတွက် ပြီးပြည့်စုံသောရှာဖွေမှုကို လုပ်ဆောင်မည်ဖြစ်သည်။ ၎င်းသည် အမြဲတမ်း စွမ်းဆောင်ရည်အပေါ် အလွန်ဆိုးရွားသော သက်ရောက်မှုရှိသည်။

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

စောင့်ကြည့်ခြင်း၏နောက်ထပ်ဥပမာ။ အရမ်းနာမည်ကြီးတဲ့သူဆိုတော့ လူတော်တော်များများက သူ့ကို အသိအမှတ်ပြုတယ်လို့ ထင်ပါတယ်။ သူတို့ရဲ့ ပရောဂျက်တွေမှာ ဘယ်သူတွေသုံးလဲ။ Prometheus? Prometheus နှင့်တွဲဖက်၍ ဤထုတ်ကုန်ကို မည်သူအသုံးပြုသနည်း။ အမှန်မှာ ဤစောင့်ကြည့်ခြင်း၏ စံသိုလှောင်ရုံတွင် PostgreSQL နှင့် လုပ်ဆောင်ရန်အတွက် ဒက်ရှ်ဘုတ်တစ်ခု ရှိသည် - postgres_exporter Prometheus။ ဒါပေမယ့် မကောင်းတဲ့အသေးစိတ်တစ်ခုတော့ ရှိတယ်။

ဂရပ်များစွာရှိသည်။ နှင့် bytes ကို စည်းလုံးမှုအဖြစ် ညွှန်ပြသည်၊ ဆိုလိုသည်မှာ ဂရပ် 5 ခုရှိသည်။ ၎င်းတို့မှာ ဒေတာထည့်သွင်းခြင်း၊ ဒေတာမွမ်းမံခြင်း၊ ဒေတာဖျက်ပစ်ခြင်း၊ ဒေတာရယူခြင်းနှင့် ဒေတာပြန်ခြင်း တို့ဖြစ်သည်။ ယူနစ်တိုင်းတာမှုမှာ ဘိုက်များဖြစ်သည်။ သို့သော် PostgreSQL တွင်ကိန်းဂဏန်းအချက်အလက်များသည် tuple (အတန်းများ) တွင်အချက်အလက်များကိုပြန်ပေးသည်မှာဖြစ်သည်။ ထို့အပြင်၊ ဤဂရပ်များသည် သင်၏လုပ်ငန်းဝန်ကို အကြိမ်များစွာ၊ အကြိမ်များစွာ လျှော့တွက်ရန် အလွန်ကောင်းမွန်သော နည်းလမ်းဖြစ်သည်၊ အကြောင်းမှာ tuple တစ်ခုသည် byte မဟုတ်ပါ၊ tuple သည် စာကြောင်းတစ်ခု၊ ၎င်းသည် များစွာသော bytes ဖြစ်ပြီး ၎င်းသည် အမြဲတမ်း ပြောင်းလဲနိုင်သော အရှည်ဖြစ်သည်။ ဆိုလိုသည်မှာ tuples ကို အသုံးပြု၍ bytes ဖြင့် workload ကို တွက်ချက်ခြင်းသည် လက်တွေ့မကျသော အလုပ် သို့မဟုတ် အလွန်ခက်ခဲပါသည်။ ထို့ကြောင့်၊ သင်သည် ဒက်ရှ်ဘုတ် သို့မဟုတ် တပ်ဆင်ထားသော စောင့်ကြည့်စစ်ဆေးခြင်းကို အသုံးပြုသောအခါ၊ ၎င်းသည် မှန်ကန်စွာ အလုပ်လုပ်ကြောင်း နားလည်ပြီး သင့်အား မှန်ကန်စွာ အကဲဖြတ်ထားသော ဒေတာကို ပြန်ပေးကြောင်း အမြဲတမ်း အရေးကြီးပါသည်။

ဤဇယားများတွင် စာရင်းအင်းများကို မည်သို့ရယူရမည်နည်း။ ဤရည်ရွယ်ချက်အတွက်၊ PostgreSQL တွင် အချို့သောအမြင်များရှိသည်။ အဓိက ကတော့ အမြင်ပါပဲ။ pg_stat_user_tables. User_tables - ၎င်းသည် အသုံးပြုသူကိုယ်စား ဖန်တီးထားသော ဇယားများကို ဆိုလိုသည်။ ဆန့်ကျင်ဘက်အားဖြင့် PostgreSQL ကိုယ်တိုင်က အသုံးပြုသည့် စနစ်အမြင်များ ရှိပါသည်။ စနစ်နှင့် အသုံးပြုသူ နှစ်ခုလုံးပါ၀င်သော အကျဉ်းချုပ်ဇယား Alltables ရှိသည်။ သင်အကြိုက်ဆုံးသော ၎င်းတို့ထဲမှ တစ်ခုမှ စတင်နိုင်သည်။

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

ဤဒေတာကိုအခြေခံ၍ ကျွန်ုပ်တို့သည် TopN ဇယားများကိုတည်ဆောက်နိုင်သည်။ ဥပမာ Top-5၊ Top-10။ ထို့အပြင် အခြားအရာများထက် ပြန်လည်အသုံးပြုထားသည့် စားပွဲပူများကို သင်ခြေရာခံနိုင်သည်။ ဥပမာ၊ ထည့်သွင်းရန်အတွက် "ပူ" ဇယား ၅ ခု။ ဤ TopN ဇယားများကိုအသုံးပြု၍ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏လုပ်ငန်းတာဝန်ကို အကဲဖြတ်ပြီး မည်သည့်ထုတ်ပြန်မှု၊ အပ်ဒိတ်များနှင့် ဖြန့်ကျက်မှုများပြီးနောက်တွင် အလုပ်ချိန်ကို အကဲဖြတ်နိုင်ပါသည်။

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

အခု မင်းအတွက် မေးခွန်းလေးတစ်ခု။ သင်၏ဒေတာဘေ့စ်ဆာဗာတွင် load ကိုသတိပြုမိသောအခါမည်သည့်မေးခွန်းပေါ်လာသနည်း။ နောက်မေးခွန်းက ဘာလဲ။

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

ထို့ကြောင့်၊ အမြင့်ဆုံး load ဖြစ်စေသော အဆိုပါမေးခွန်းများကို သင်ရှာဖွေရန်လိုအပ်သည်၊ အဘယ်ကြောင့်ဆိုသော် tuning queries သည် စည်းကမ်းအတိုင်း PostgreSQL သို့မဟုတ် operating system configuration ကို ချိန်ညှိခြင်းထက် အမြတ်ပိုပေးသည်၊ သို့မဟုတ် hardware ကိုချိန်ညှိခြင်းပင်ဖြစ်ပါသည်။ ကျွန်ုပ်၏ခန့်မှန်းချက်အရ၊ ဤသည်ခန့်မှန်းခြေအားဖြင့် 80-85-90% ဖြစ်သည်။ ပြီးတော့ ဒါက ပိုမြန်တယ်။ ဖွဲ့စည်းပုံအခြေခံဥပဒေကို ပြင်ရန်၊ အထူးသဖြင့် ဒေတာဘေ့စ်ကို ပြန်လည်စတင်၍မရပါက သို့မဟုတ် ဟာ့ဒ်ဝဲလ်ထည့်ပါက ပြန်လည်စတင်ရန် အချိန်ဇယားထက် တောင်းဆိုချက်တစ်ခုကို ပြင်ရန် ပိုမိုမြန်ဆန်သည်။ မေးခွန်းကို တစ်နေရာရာတွင် ပြန်ရေးရန် သို့မဟုတ် ဤမေးမြန်းချက်မှ ပိုမိုကောင်းမွန်သောရလဒ်ရရှိရန် အညွှန်းတစ်ခုထည့်ရန် လွယ်ကူသည်။

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

ဤအချက်အလက်ရရန် pg_stat_statements module ကိုသုံးနိုင်သည်။ ၎င်းကိုအခြေခံ၍ သင်သည် ဂရပ်အမျိုးမျိုးကို တည်ဆောက်နိုင်သည်။ ဥပမာအားဖြင့်၊ အမေးများဆုံးမေးခွန်းများ ၊ ဆိုလိုသည်မှာ မကြာခဏလုပ်ဆောင်သော queries များပေါ်တွင် အချက်အလက်များကို သင်ရနိုင်သည်။ ဟုတ်ကဲ့၊ ဖြန့်ကျက်ပြီးနောက် ၎င်းကိုကြည့်ရှုပြီး တောင်းဆိုမှုများတွင် မြင့်တက်လာခြင်းရှိမရှိ နားလည်ရန်မှာလည်း အလွန်အသုံးဝင်ပါသည်။

အရှည်ဆုံးမေးခွန်းများကို သင်စောင့်ကြည့်နိုင်သည်၊ ဆိုလိုသည်မှာ ပြီးမြောက်ရန် အကြာဆုံးအချိန်ယူသော မေးခွန်းများဖြစ်သည်။ ၎င်းတို့သည် ပရိုဆက်ဆာပေါ်တွင် အလုပ်လုပ်ပြီး I/O ကို စားသုံးကြသည်။ အကွက်စုစုပေါင်း_အချိန်၊ ပျမ်းမျှ_အချိန်၊ blk_write_time နှင့် blk_read_time တို့ကိုလည်း အကဲဖြတ်နိုင်သည်။

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

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

ယာယီဖိုင်များ သို့မဟုတ် ယာယီဇယားများကို အသုံးပြုသည့် မေးမြန်းချက်များကိုလည်း စောင့်ကြည့်နိုင်သည်။

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

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

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

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

ထို့ကြောင့်၊ pg_stat_bgwriter မှသတ်မှတ်ထားသောကွက်လပ်များကိုအသုံးပြုခြင်းအားဖြင့်ဖြစ်ပေါ်သည့်စစ်ဆေးရေးဂိတ်အရေအတွက်ကိုကျွန်ုပ်တို့စောင့်ကြည့်နိုင်သည်။ အကယ်၍ ကျွန်ုပ်တို့တွင် အချိန်အတိုင်းအတာတစ်ခုအထိ (၁၀-၁၅-၂၀ မိနစ်၊ နာရီဝက်အတွင်း)၊ ဥပမာ၊ ၃-၄-၅ တွင် စစ်ဆေးရေးဂိတ်များစွာရှိလျှင် ဤသည်မှာ ပြဿနာဖြစ်နေပြီဖြစ်သည်။ ဒေတာဘေ့စ်တွင်ကြည့်ရှုရန်၊ ဖွဲ့စည်းမှုပုံစံတွင်ကြည့်ပါ၊ ယင်းသို့များပြားသောစစ်ဆေးရေးဂိတ်များကိုဘာကြောင့်ဖြစ်စေသနည်း။ ကြီးကြီးမားမား မှတ်တမ်းတင်တာမျိုးတွေ ရှိကောင်းရှိနိုင်ပါတယ်။ ကျွန်ုပ်တို့သည် workload ဂရပ်များကို ပေါင်းထည့်ထားပြီးဖြစ်သောကြောင့် အလုပ်တာဝန်ကို အကဲဖြတ်နိုင်ပါပြီ။ ကျွန်ုပ်တို့သည် စစ်ဆေးရေးဂိတ်ဘောင်များကို ပြုပြင်ပြောင်းလဲပြီးဖြစ်ပြီး ၎င်းတို့သည် မေးမြန်းမှုစွမ်းဆောင်ရည်ကို ကြီးကြီးမားမားမထိခိုက်စေကြောင်း သေချာစေပါသည်။

ငါပြောခဲ့သည့်အတိုင်း autovacuum သို့တစ်ဖန်ပြန်လာတော့မည်ဖြစ်သောကြောင့် disk နှင့် query performance နှစ်ခုလုံးကိုအလွယ်တကူပေါင်းထည့်နိုင်သောအရာဖြစ်သောကြောင့် autovacuum ပမာဏကိုခန့်မှန်းရန်အမြဲအရေးကြီးပါသည်။

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

လေဟာနယ်၏ကြာချိန်၊ အကယ်၍ ကျွန်ုပ်တို့တွင် အချိန်အကြာကြီးလည်ပတ်နေသော ကြာရှည်ခံလေဟာနယ်များရှိပါက၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် လေဟာနယ်ဖွဲ့စည်းပုံကို ထပ်မံအာရုံစိုက်ရန် လိုအပ်ပြီး ၎င်း၏ဆက်တင်များကို ပြန်လည်စဉ်းစားရန် လိုအပ်သည်ဟု ဆိုလိုသည်။ အဘယ်ကြောင့်ဆိုသော် လေဟာနယ်သည် စားပွဲပေါ်တွင် အချိန်ကြာမြင့်စွာ (၃-၄ နာရီ) အလုပ်လုပ်သောအခါတွင် အခြေအနေတစ်ခု ဖြစ်ပေါ်လာနိုင်သော်လည်း လေဟာနယ်အလုပ်လုပ်နေချိန်အတွင်း အတန်းလိုက်သေတ္တာအများအပြားသည် စားပွဲပေါ်တွင် ထပ်မံစုပုံလာခဲ့သည်။ လေဟာနယ် ပြီးတာနဲ့၊ သူက ဒီစားပွဲကို နောက်တစ်ကြိမ် ဖုန်စုပ်ဖို့ လိုတယ်။ ပြီးတော့ အဆုံးမဲ့ လေဟာနယ်တစ်ခုဖြစ်တဲ့ အခြေအနေတစ်ခုကို ရောက်သွားတယ်။ ဤကိစ္စတွင်၊ လေဟာနယ်သည် ၎င်း၏လုပ်ငန်းကို မကိုင်တွယ်နိုင်ဘဲ၊ ၎င်းတွင် အသုံးဝင်သောဒေတာပမာဏသည် အတူတူပင်ဖြစ်သော်လည်း ဇယားများသည် တဖြည်းဖြည်း ဖောင်းကားလာပါသည်။ ထို့ကြောင့်၊ ကာလအတန်ကြာ လေဟာနယ်အတွင်းတွင်၊ ကျွန်ုပ်တို့သည် ဖွဲ့စည်းမှုပုံစံကို အမြဲကြည့်ရှုပြီး ၎င်းကို အကောင်းဆုံးဖြစ်အောင် ကြိုးစားသော်လည်း တစ်ချိန်တည်းတွင် သုံးစွဲသူများ၏ တောင်းဆိုမှုများ၏ စွမ်းဆောင်ရည်ကို မထိခိုက်စေရန်အတွက် ဖြစ်သည်။

ယခုအချိန်တွင် streaming replication မပါသော PostgreSQL တပ်ဆင်ခြင်းမှာ လက်တွေ့တွင်မရှိပါ။ ကူးယူခြင်းဆိုသည်မှာ အချက်အလက်များကို မာစတာမှ ပုံတူတစ်ခုသို့ ရွှေ့ပြောင်းခြင်းလုပ်ငန်းစဉ်ဖြစ်သည်။

PostgreSQL တွင် ကူးယူမှုမှတ်တမ်းတစ်ခုမှတစ်ဆင့် ကူးယူဖော်ပြပါသည်။ wizard သည် ငွေပေးငွေယူ မှတ်တမ်းတစ်ခုကို ထုတ်ပေးသည်။ ငွေပေးငွေယူ မှတ်တမ်းသည် ပုံစံတူသို့ ကွန်ရက်ချိတ်ဆက်မှုမှ ဖြတ်သန်းသွားပြီးနောက် ၎င်းကို ပုံစံတူပေါ်တွင် ပြန်ထုတ်ပေးပါသည်။ ရိုးရှင်းပါတယ်။

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

မည်သို့ပင်ဆိုစေကာမူ၊ replication lag ကိုအကဲဖြတ်ရန်အတွက်၊ ငွေသွင်းငွေထုတ်စာရင်း၏တည်နေရာကိုသင်သိရန်လိုအပ်သည်။ ဤငွေပေးငွေယူမှတ်တမ်း ရာထူးများသည် pg_stat_replication မြင်ကွင်းတွင် အတိအကျရှိပါသည်။ နှိုင်းယှဉ်ပြောရလျှင် pg_xlog_location_diff() လုပ်ဆောင်ချက်ကို အသုံးပြု၍ ငွေပေးငွေယူမှတ်တမ်းတွင် အမှတ်နှစ်မှတ်ယူနိုင်သည်။ ၎င်းတို့ကြားရှိ မြစ်ဝကျွန်းပေါ်ဒေသကို တွက်ချက်ပြီး ဘိုက်ဖြင့် ကူးယူခြင်း နောက်ကျခြင်းကို ရယူပါ။ အရမ်းအဆင်ပြေပြီး ရိုးရှင်းပါတယ်။

ဗားရှင်း 10 တွင်၊ ဤလုပ်ဆောင်ချက်ကို pg_wal_lsn_diff() ဟု အမည်ပြောင်းခဲ့သည်။ ယေဘုယျအားဖြင့် “xlog” ဟူသော စကားလုံးပေါ်လာသည့် လုပ်ဆောင်ချက်များ၊ အမြင်များနှင့် အသုံးအဆောင်များအားလုံးတွင် ၎င်းကို “wal” တန်ဖိုးဖြင့် အစားထိုးထားသည်။ ၎င်းသည် အမြင်များနှင့် လုပ်ဆောင်ချက်များ နှစ်ခုလုံးအတွက် အကျုံးဝင်ပါသည်။ ဒါက ဆန်းသစ်တီထွင်မှုတစ်ခုပါ။

ထို့အပြင်၊ ဗားရှင်း 10 တွင် နှေးကွေးမှုကို အထူးဖော်ပြသည့် လိုင်းများကို ထည့်သွင်းထားသည်။ ဒါတွေက ရေးတာနောက်ကျတာ၊ flush lag နဲ့ replay lag တွေပါ။ ဆိုလိုသည်မှာ ဤအရာများကို စောင့်ကြည့်ရန် အရေးကြီးပါသည်။ ကျွန်ုပ်တို့တွင် ပုံတူကူးချခြင်း နောက်ကျနေခြင်းကို တွေ့ရှိပါက၊ ၎င်းသည် အဘယ်ကြောင့် ပေါ်လာကြောင်း၊ မည်သည့်နေရာက လာသည်နှင့် ပြဿနာကို ဖြေရှင်းရန် လိုအပ်ပါသည်။

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

အကယ်၍ အရာအားလုံးသည် ပြန်လည်အသုံးပြုခြင်း လုပ်ငန်းစဉ်ဖြင့် စနစ်တကျဖြစ်ပါက၊ ထို့နောက် disk ပြန်လည်အသုံးပြုခြင်းတွင် ပြဿနာများရှိသည်။ စည်းကမ်းအတိုင်း၊ စောင့်ကြည့်လေ့လာသည့် developer များသည် throughput နှင့်ပတ်သက်သော အချက်အလက်များကို ပေါင်းထည့်သည်။ ၎င်းသည် iops သို့မဟုတ် bytes တွင်ရှိနိုင်သည်။ သို့သော် ၎င်းတို့သည် latency နှင့် disk devices များအသုံးပြုမှုကို မေ့သွားကြသည်။ ဤအရာများသည် ကျွန်ုပ်တို့၏ဒစ်များမည်မျှ loaded နှင့် ၎င်းတို့မည်မျှနှေးသည်ကို အကဲဖြတ်နိုင်စေသည့် ပိုအရေးကြီးသောဘောင်များဖြစ်သည်။ ကျွန်ုပ်တို့တွင် latency မြင့်မားပါက၊ ၎င်းသည် disks များတွင် ပြဿနာအချို့ရှိနေသည်ဟု ဆိုလိုသည်။ ကျွန်ုပ်တို့တွင် အသုံးချမှု မြင့်မားပါက၊ ၎င်းသည် disks များကို ကိုင်တွယ်ဖြေရှင်းခြင်း မပြုဟု ဆိုလိုသည်။ ဤအရာများသည် ဖြတ်သန်းမှုထက် ပိုမိုကောင်းမွန်သော လက္ခဏာများဖြစ်သည်။

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

ကွန်ရက်အင်တာဖေ့စ်များနှင့် အလားတူသည်။ ပက်ကတ်များ၊ ဘိုက်များတွင် ကွန်ရက်ဖြတ်သန်းမှုဆိုင်ရာ သတင်းအချက်အလက်များ ရှိသည်၊ သို့သော် ၎င်းသည် အသုံးဝင်သော အချက်အလက်ဖြစ်သော်လည်း၊ latency အကြောင်းနှင့် အသုံးချမှုဆိုင်ရာ အချက်အလက်များ မရှိပေ။

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

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

အချို့သော အဓိကအချက်များ-

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

ဒီအကြောင်းအရာကို စိတ်ဝင်စားတယ်ဆိုရင် ဒီလင့်ခ်တွေကို လိုက်ကြည့်နိုင်ပါတယ်။
http://bit.do/stats_collector - ဤသည်မှာ စာရင်းဇယားစုဆောင်းသူထံမှ တရားဝင်စာရွက်စာတမ်းဖြစ်သည်။ ကိန်းဂဏန်းအမြင်အားလုံး၏ ဖော်ပြချက်နှင့် အကွက်အားလုံး၏ ဖော်ပြချက်တစ်ခုရှိသည်။ ၎င်းတို့ကို ဖတ်နိုင်၊ နားလည်နိုင်ပြီး ခွဲခြမ်းစိတ်ဖြာနိုင်သည်။ ၎င်းတို့အပေါ် အခြေခံ၍ သင့်ဂရပ်ဖစ်များကို တည်ဆောက်ပြီး သင့်စောင့်ကြည့်မှုတွင် ၎င်းတို့ကို ထည့်ပါ။

ဥပမာ တောင်းဆိုချက်များ
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

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

မေးခွန်း- အမှတ်တံဆိပ်တွေကို ကြော်ငြာမှာမဟုတ်ဘူးလို့ မင်းပြောခဲ့တယ်၊ ဒါပေမယ့် ငါသိချင်နေတုန်းပဲ- မင်းရဲ့ပရောဂျက်တွေမှာ ဘယ်လို dashboards အမျိုးအစားတွေကို သုံးတာလဲ။
အဖြေ: ကွဲပြားသည်။ ကျွန်ုပ်တို့သည် ဖောက်သည်တစ်ဦးထံ ရောက်ရှိလာပြီး သူ့တွင် သူ့ကိုယ်ပိုင် စောင့်ကြည့်မှု ရှိပြီးဖြစ်သည်။ ထို့အပြင် ၎င်းတို့၏ စောင့်ကြည့်မှုတွင် ထည့်သွင်းရန် လိုအပ်သည်များကို ဖောက်သည်အား ကျွန်ုပ်တို့ အကြံပေးပါသည်။ အဆိုးဆုံးအခြေအနေမှာ Zabbix ဖြစ်သည်။ TopN ဂရပ်များကိုတည်ဆောက်နိုင်စွမ်းမရှိသောကြောင့်ဖြစ်သည်။ ငါတို့ကိုယ်တိုင်သုံးတယ်။ Okmeterဘာဖြစ်လို့လဲဆိုတော့ ကျနော်တို့က ဒီကောင်တွေနဲ့ တိုင်ပင်ပြီး စောင့်ကြည့်နေတယ်။ ၎င်းတို့သည် ကျွန်ုပ်တို့၏ နည်းပညာဆိုင်ရာ သတ်မှတ်ချက်များအပေါ် အခြေခံ၍ PostgreSQL ကို စောင့်ကြည့်ခဲ့သည်။ ကျွန်ုပ်သည် Prometheus မှတစ်ဆင့် အချက်အလက်များကို စုဆောင်းပြီး ၎င်းကို တင်ဆက်ပေးသည့် ကျွန်ုပ်၏ကိုယ်ပိုင် အိမ်မွေးတိရစ္ဆာန်ပရောဂျက်ကို ရေးသားနေပါသည်။ Grafana. ကျွန်ုပ်၏တာဝန်မှာ Prometheus တွင် ကျွန်ုပ်၏ကိုယ်ပိုင်ပို့ကုန်ထုတ်လုပ်သူအား ဖန်တီးပြီး Grafana တွင် အရာအားလုံးကို တင်ဆက်ရန်ဖြစ်သည်။

မေးခွန်း- AWR အစီရင်ခံစာများ သို့မဟုတ် ... စုစည်းမှု၏ တူညီသော တူညီချက်များ ရှိပါသလား။ ဒီလိုမျိုး တစ်ခုခုအကြောင်း မင်းသိလား။
ဖြေ- ဟုတ်ကဲ့၊ AWR ဆိုတာ ဘာလဲဆိုတာ ကျွန်တော် သိပါတယ်၊ ဒါက မိုက်တယ်။ လောလောဆယ်တွင် အောက်ဖော်ပြပါ မော်ဒယ်ကို ခန့်မှန်းခြေအားဖြင့် အကောင်အထည်ဖော်သော စက်ဘီးအမျိုးမျိုးရှိသည်။ အချိန်အတိုင်းအတာတစ်ခုအတွင်း၊ အချို့သောအခြေခံအချက်များကို တူညီသော PostgreSQL သို့မဟုတ် သီးခြားသိုလှောင်မှုသို့ ရေးထားသည်။ ၎င်းတို့ကို အင်တာနက်ပေါ်တွင် သင် google လုပ်နိုင်သည်၊ ၎င်းတို့သည် ထိုနေရာတွင် ရှိနေသည်။ ထိုအရာ၏ developer များထဲမှတစ်ယောက်က PostgreSQL thread ရှိ sql.ru ဖိုရမ်တွင် ထိုင်နေသည်။ အဲဒီမှာ သူ့ကိုဖမ်းလို့ရတယ်။ ဟုတ်တယ်၊ အဲလိုအရာတွေရှိတယ်၊ သူတို့ကသုံးနိုင်တယ်။ အပေါင်းပါ pgCenter ငါ မင်းကို ဒီလိုပဲ လုပ်ခွင့်ပေးတဲ့ အရာတစ်ခုကိုလည်း ငါရေးနေတယ်။

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

PS2 သည် စွမ်းဆောင်ရည်စောင့်ကြည့်ခြင်းနှင့် အလိုအလျောက်ချိန်ညှိခြင်းဆိုင်ရာ အကြံပြုချက်များကို အလေးပေးထားသည့် မူပိုင် SaaS ကမ်းလှမ်းချက်ဖြစ်သောကြောင့် ဖယ်ရှားလိုက်ခြင်းဖြစ်သည်။

စာရင်းသွင်းအသုံးပြုသူများသာ စစ်တမ်းတွင် ပါဝင်နိုင်ပါသည်။ ဆိုင်းအင်လုပ်ခြင်း, ကျေးဇူးပြု။

မည်သည့် self-hosted postgresql monitoring (ဒက်ရှ်ဘုတ်ဖြင့်) အကောင်းဆုံးဟု သင်ယူဆသနည်း။

• 30,0%Zabbix + Alexey Lesovsky သို့မဟုတ် zabbix 4.4 သို့မဟုတ် libzbxpgsql + zabbix libzbxpgsql + zabbix3 မှ ထပ်တိုးမှုများ

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze သည် ကိုယ်ပိုင် SaaS တစ်ခုဖြစ်သည် - ၎င်းကို ဖျက်၍မရပါ။

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

အသုံးပြုသူ 10 ဦး မဲပေးခဲ့သည်။ အသုံးပြုသူ 26 ရှောင်နေခဲ့ပါတယ်။

source: www.habr.com