postgresql တွင် ဖောင်းပွစေသော အပလီကေးရှင်းများတွင် ပုံမှန်အမှားများ။ Andrey Salnikov

Andrey Salnikov ၏ "postgresql တွင် ဖောင်းပွစေသော အပလီကေးရှင်းများတွင် ပုံမှန်အမှားအယွင်းများ" မှ 2016 ခုနှစ်အစမှ အစီရင်ခံစာ၏ စာသားမှတ်တမ်းကို ဖတ်ရန် ကျွန်ုပ်အကြံပြုအပ်ပါသည်။

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

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

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

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

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

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

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

ပြီးတော့ ဒီအခြေအနေမှာ၊ ငါတို့မှာ တကယ်ကို သေးငယ်တဲ့ လက္ခဏာတစ်ခု ရှိနေတာကို ငါတို့မြင်တယ်။ အညွှန်းသည် 2 MB တွင် သေးငယ်သည်။ ဤသည်မှာ ဘယ်ဘက်ရှိ ပထမဂရပ်ဖြစ်သည်။

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

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

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

မွမ်းမံမွမ်းမံခြင်းမပြုမီ ကျွန်ုပ်တို့၏အလိုရှိသောလိုင်းကို ရှာဖွေရာတွင် ကျွန်ုပ်တို့၏လည်ပတ်မှုနှင့် disk memory မည်မျှရှိသည်ကို ညာဘက်အောက်ဂရပ်တွင် ပြသသည်။ နိမိတ်လက္ခဏာအရ လည်ပတ်မှုအရေအတွက်သည် အစတွင် ငါပြောခဲ့သည့်အတိုင်း တစ်စက္ကန့်လျှင် ၂၀၀၀ ဖြစ်သည်။

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

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

ဒီလိုအရာတွေက ဘယ်ကို ဦးတည်သွားတာလဲ။

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

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

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

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

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

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

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

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

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

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

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

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

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

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

မတော်တဆမှုအတွင်း ဘာတွေဖြစ်ခဲ့လဲ။ အဲဒီဖြစ်စဉ်က ဘယ်လိုဖြစ်တာလဲ။

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

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

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

ကျွန်ုပ်တို့ query တစ်ခုကို လုပ်ဆောင်သောအခါ၊ ဒေတာဘေ့စ်သည် လိုချင်သောလိုင်းကိုရှာဖွေရန် အနီရောင်နှင့် အစိမ်းရောင် နှစ်ခုစလုံးကို ဖြတ်သွားရမည်ဖြစ်သည်။ အသုံးမဝင်သောဒေတာများဖြင့် စားပွဲတစ်လုံးကို ဖောင်းပွခြင်း၏အကျိုးသက်ရောက်မှုကို "bloat" ဟုခေါ်သည်၊ ၎င်းသည် ကျွန်ုပ်တို့၏ဒစ်နေရာကိုလည်းစားစေသည်။ 2 MB ၊ 300 MB ဖြစ်သွားတာကို သတိရပါ။ ယခု megabytes ကို gigabyte သို့ပြောင်းပြီး သင်၏ disk အရင်းအမြစ်များအားလုံးကို လျင်မြန်စွာ ဆုံးရှုံးမည်ဖြစ်ပါသည်။

ကျွန်ုပ်တို့အတွက် မည်သည့်အကျိုးဆက်များ ရှိနိုင်မည်နည်း။

• ကျွန်ုပ်၏ဥပမာတွင်၊ ဇယားနှင့်အညွှန်းကိန်းသည် အဆ ၁၅၀ တိုးလာသည်။ ကျွန်ုပ်တို့၏ဖောက်သည်အချို့သည် ဒစ်ခ်နေရာလွတ်ကုန်သွားသောအခါတွင် ကျွန်ုပ်တို့၏ဖောက်သည်များသည် ပို၍သေစေသောဖြစ်ရပ်များရှိသည်။
• စားပွဲတွေရဲ့ အရွယ်အစားဟာ ဘယ်တော့မှ လျော့သွားမှာ မဟုတ်ပါဘူး။ အချို့ကိစ္စများတွင် Autovacuum သည် dead line များသာရှိလျှင် စားပွဲ၏အမြီးကို ဖြတ်နိုင်သည်။ သို့သော် အဆက်မပြတ်လည်ပတ်နေသောကြောင့်၊ အစိမ်းရောင်မျဉ်းတစ်ကြောင်းသည် အဆုံးတွင် အေးခဲသွားပြီး အပ်ဒိတ်လုပ်မည်မဟုတ်သော်လည်း ကျန်အားလုံးကို ပန်းကန်၏အစတွင် ရေးမှတ်ထားမည်ဖြစ်သည်။ ဒါပေမယ့် ဒါက သင့်စားပွဲကိုယ်တိုင်က အရွယ်အစားကျုံ့သွားမယ့် မဖြစ်နိုင်တဲ့ အဖြစ်အပျက်တစ်ခုပါ၊ ဒါကြောင့် အဲဒါကို သင်မမျှော်လင့်သင့်ပါဘူး။
• ဒေတာဘေ့စ်သည် အသုံးမဝင်သော လိုင်းများအားလုံးကို စီရန် လိုအပ်သည်။ ကျွန်ုပ်တို့သည် ဒစ်ခ်အရင်းအမြစ်များကို ဖြုန်းတီးကာ ပရိုဆက်ဆာအရင်းအမြစ်များနှင့် လျှပ်စစ်ဓာတ်အားကို ဖြုန်းတီးကြသည်။
• အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် ကျွန်ုပ်တို့၏လျှောက်လွှာကို တိုက်ရိုက်အကျိုးသက်ရောက်သည်၊ အဘယ်ကြောင့်ဆိုသော် အစပိုင်းတွင် ကျွန်ုပ်တို့သည် တောင်းဆိုမှုတွင် 10 မီလီစက္ကန့်၊ ကျွန်ုပ်တို့၏ကုဒ်တွင် 10 မီလီစက္ကန့်ကို အသုံးပြုခဲ့ပါက၊ ထို့နောက် ပျက်စီးသွားချိန်တွင် ကျွန်ုပ်တို့သည် တောင်းဆိုမှုအပေါ် တစ်စက္ကန့်နှင့် ကုဒ်အတွက် 10 မီလီစက္ကန့်ကို စတင်သုံးစွဲခဲ့သည်၊ ဆိုလိုသည်မှာ အမိန့်တစ်ခုဖြစ်သည်။ အက်ပလီကေးရှင်း၏ စွမ်းဆောင်ရည် ပြင်းအား ကျဆင်းသွားသည်။ မတော်တဆမှုကို ဖြေရှင်းပြီးသောအခါ၊ ကျွန်ုပ်တို့သည် တောင်းဆိုချက်တစ်ခုအတွက် 20 မီလီစက္ကန့်၊ ကုဒ်တစ်ခုအတွက် 10 မီလီစက္ကန့်ကို စတင်သုံးစွဲခဲ့သည်။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် ကုန်ထုတ်စွမ်းအားကို တစ်ဆခွဲဖြင့် ကျဆင်းနေဆဲဖြစ်သည်။ ဤအရာအားလုံးသည် ကျွန်ုပ်တို့၏အမှားကြောင့် ဖြစ်ကောင်းဖြစ်နိုင်သည့် အရောင်းအဝယ်တစ်ခု ရပ်တန့်သွားခြင်းကြောင့်ဖြစ်သည်။
• ပြီးတော့ မေးခွန်းက “အရာရာကို ဘယ်လိုပြန်ရနိုင်မလဲ” ဆိုတော့ အားလုံးအဆင်ပြေပြီး မတော်တဆမှုမဖြစ်ခင်မှာ တောင်းဆိုမှုတွေ အမြန်ဝင်လာဖို့ပါ။

ဤရည်ရွယ်ချက်အတွက် လုပ်ဆောင်ရမည့် အလုပ်သံသရာတစ်ခုရှိသည်။

ပထမဦးစွာ ဖောင်းပွနေသော ပြဿနာရှိသော စားပွဲများကို ရှာဖွေရန် လိုအပ်သည်။ အချို့ဇယားများတွင် အသံသွင်းခြင်းသည် ပိုမိုတက်ကြွကြောင်း၊ အချို့ဇယားများတွင် လှုပ်ရှားမှုနည်းသည်ကို ကျွန်ုပ်တို့နားလည်ပါသည်။ ၎င်းအတွက်ကျွန်ုပ်တို့သည် extension ကိုအသုံးပြုသည်။ pgstattuple. ဤတိုးချဲ့မှုကို ထည့်သွင်းခြင်းဖြင့်၊ သင်သည် အလွန်ဖောင်းကားနေသော ဇယားများကို ရှာဖွေရန် ကူညီပေးမည့် queries များကို ရေးသားနိုင်သည်။

ဤဇယားများကို သင်တွေ့ပြီးသည်နှင့် ၎င်းတို့ကို ချုံ့ရန် လိုအပ်သည်။ ဒီအတွက် ကိရိယာတွေ ရှိပြီးသားပါ။ ကျွန်ုပ်တို့၏ကုမ္ပဏီတွင် ကျွန်ုပ်တို့သည် ကိရိယာသုံးခုကို အသုံးပြုသည်။ ပထမတစ်ခုကတော့ Built-in VACUUM FULL ဖြစ်ပါတယ်။ သူသည် ရက်စက်ကြမ်းကြုတ်ပြီး သနားညှာတာတတ်သော်လည်း တစ်ခါတစ်ရံ အလွန်အသုံးဝင်သည်။ Pg_repack и pgcompactable - ဤအရာများသည် ဇယားများကို ချုံ့ရန်အတွက် ပြင်ပအဖွဲ့အစည်း အသုံးဝင်မှုများဖြစ်သည်။ ပြီးတော့ သူတို့က database ကို ပိုဂရုတစိုက်ဆက်ဆံတယ်။

၎င်းတို့ကို သင့်အတွက် ပိုအဆင်ပြေသည့်အရာပေါ် မူတည်၍ အသုံးပြုသည်။ ဒါပေမယ့် ဒီအကြောင်းကို အဆုံးမှာ ပြောပြမယ်။ အဓိကအချက်ကတော့ tool သုံးခုရှိပါတယ်။ ရွေးချယ်စရာတွေ အများကြီးရှိတယ်။

ကျွန်ုပ်တို့သည် အရာအားလုံးကို ပြုပြင်ပြီး အားလုံးအဆင်ပြေကြောင်း သေချာအောင်လုပ်ပြီးနောက်၊ အနာဂတ်တွင် ဤအခြေအနေကို မည်သို့တားဆီးရမည်ကို သိထားရမည်-

• အလွယ်တကူ တားဆီးနိုင်ပါတယ်။ Master server တွင် session များ၏ကြာချိန်ကိုသင်စောင့်ကြည့်ရန်လိုအပ်သည်။ အထူးသဖြင့် အရောင်းအ၀ယ်အခြေအနေတွင် ရပ်နားထားသော အန္တရာယ်ရှိသော ဆက်ရှင်များ. ၎င်းတို့သည် ငွေပေးငွေယူတစ်ခုဖွင့်လိုက်၊ တစ်ခုခုလုပ်ကာ ထွက်သွားသည်၊ သို့မဟုတ် ရိုးရိုးချိတ်ဆွဲထားလိုက်၊ ကုဒ်ထဲတွင် ပျောက်ဆုံးသွားသူများဖြစ်သည်။
• ဆော့ဖ်ဝဲရေးသားသူများအနေဖြင့် သင့်အတွက်၊ ဤအခြေအနေများပေါ်ပေါက်လာသောအခါတွင် သင့်ကုဒ်ကို စမ်းသပ်ရန် အရေးကြီးပါသည်။ လုပ်ရတာ မခက်ပါဘူး။ ဒါက အသုံးဝင်တဲ့ စစ်ဆေးမှုတစ်ခု ဖြစ်ပါလိမ့်မယ်။ ရှည်လျားသောငွေကြေးလွှဲပြောင်းမှုများနှင့်ဆက်စပ်သော "ကလေးဆန်သော" ပြဿနာအများအပြားကို သင်ရှောင်ရှားနိုင်မည်ဖြစ်သည်။

ဤဂရပ်များတွင်၊ ဤကိစ္စတွင် ကျွန်ုပ်သည် VACUUM FULL ဖြင့် နိမိတ်ဖတ်ပြီးနောက် ဒေတာဘေ့စ်၏ နိမိတ်လက္ခဏာနှင့် အမူအကျင့်များ မည်သို့ပြောင်းလဲသွားသည်ကို သင့်အား ပြသလိုပါသည်။ ဒါက ကျွန်တော့်အတွက် ထုတ်လုပ်မှုမဟုတ်ပါဘူး။

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

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

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

ကျွန်ုပ်တို့သည် ဝန်ကိုဖြန့်ဝေပြီး ဆာဗာရင်းမြစ်များကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်သည့် ဒုတိယဇာတ်လမ်း

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

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

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

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

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

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

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

အားလုံးပြီးပြည့်စုံစေချင်တယ်။ ငါတို့ ပိုတက်တယ်။ hot_standby_feedback အင်တာနက်မှာ အေးမြတဲ့ဆက်တင်တစ်ခုကို တွေ့ခဲ့ကြတယ်။ ဖွင့်ကြည့်ရအောင်။ Hot_standby_feedback သည် Master ရှိ autovacuum ကို ထိန်းထားနိုင်စေပါသည်။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ပုံတူပွားခြင်းဆိုင်ရာ ပဋိပက္ခများကို လုံးဝဖယ်ရှားပစ်ပါသည်။ ပြီးတော့ အရာအားလုံးက ကျွန်တော်တို့အတွက် ကောင်းကောင်းအလုပ်လုပ်ပါတယ်။

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

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

အရင်က ငါပြောနေတာတွေကို မသိရင် ဘယ်လိုဖြစ်မလဲ။

• ကျွန်ုပ်တို့သည် ပြဿနာများကို စတင်ရှာဖွေနေပါသည်။ ပထမအပိုင်းတွင် ပြဿနာများကြုံတွေ့ပါက၊ ၎င်းသည် ရှည်လျားသောငွေပေးငွေယူကြောင့် ဖြစ်နိုင်ကြောင်းနှင့် Master သို့သွားပါ။ ဆရာကြီးမှာ ပြဿနာရှိတယ်။ သူ့ကို ဝက်အူချောင်းတွေ ၊ ပူလာတယ်၊ သူ့ရဲ့ Load ပျမ်းမျှက တစ်ရာလောက်ရှိတယ်။
• တောင်းဆိုမှုများမှာ နှေးကွေးသော်လည်း ထိုနေရာတွင် ကာလရှည်ကြာ ငွေပေးငွေယူ မတွေ့ရတော့ပါ။ ပြီးတော့ ငါတို့က ဘာကိစ္စရှိလို့လဲ မသိဘူး။ ဘယ်မှာကြည့်ရမှန်း နားမလည်ဘူး။
• ကျွန်ုပ်တို့သည် ဆာဗာပစ္စည်းများကို စစ်ဆေးပါသည်။ ကျွန်တော်တို့ရဲ့ စီးနင်းမှု ပျက်သွားနိုင်တယ်။ ကျွန်တော်တို့ရဲ့ memory stick မီးလောင်သွားတာ ဖြစ်နိုင်တယ်။ ဟုတ်တယ်၊ ဘာမဆိုဖြစ်နိုင်တယ်။ ဒါပေမယ့် မဟုတ်ဘူး၊ ဆာဗာတွေက အသစ်ဖြစ်ပြီး အရာအားလုံး အဆင်ပြေပါတယ်။
• လူတိုင်း လုပ်ဆောင်နေသည်- စီမံခန့်ခွဲသူများ၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများနှင့် ဒါရိုက်တာ။ ဘာမှ မကူညီဘူး။
• တစ်ချိန်ချိန်မှာတော့ အရာအားလုံးဟာ သူ့အလိုလို မှန်ကန်သွားပါတော့တယ်။

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

session ပြီးသွားပါပြီ။ အချိန်အနည်းငယ်ကြာပြီးမှသာ ဆာဗာသည် အစီအစဥ် အနည်းနှင့်အများ လာပါသည်။ မာစတာဆာဗာရှိ တောင်းဆိုမှုများအတွက် ပျမ်းမျှတုံ့ပြန်ချိန်သည် ပုံမှန်အတိုင်း ပြန်လည်ရောက်ရှိသွားပါသည်။ အဘယ်ကြောင့်ဆိုသော်၊ နောက်ဆုံးတွင်၊ autovacuum သည် ဤ dead line များကို ရှင်းထုတ်ပြီး အမှတ်အသားပြုရန် အခွင့်အရေးရှိသည်။ ပြီးတော့ သူ့အလုပ်ကို စလုပ်တယ်။ ပြီးတော့ သူဘယ်လောက်မြန်မြန်လုပ်တယ်၊ ငါတို့က မြန်မြန်ရလိမ့်မယ်။

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

မည်သို့ပင်ဆိုစေ၊ ကျွန်ုပ်တို့သည် ပထမကိစ္စတွင်ကဲ့သို့ပင်၊ တစ်နှစ်ခွဲမှ နှစ်ကြိမ်အထိ၊ နှင့် တစ်ခါတစ်ရံတွင် ထို့ထက်ပိုပါသည်။

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

• hot_standby_feedback ကို ဖွင့်မထားပါ။ ဟုတ်ကဲ့၊ အထူးခိုင်လုံသောအကြောင်းပြချက်မရှိဘဲ ၎င်းကိုဖွင့်ရန် မအကြံပြုပါ။ ဤလှည့်ကွက်သည် Master ဆာဗာကို တိုက်ရိုက်သက်ရောက်ပြီး ထိုနေရာတွင် autovacuum ၏လည်ပတ်မှုကို ရပ်ဆိုင်းထားသောကြောင့်ဖြစ်သည်။ ပုံတူအချို့တွင် ၎င်းကိုဖွင့်ပြီး ၎င်းကိုမေ့ခြင်းဖြင့်၊ သင်သည် Master ကိုသတ်ပြီး အက်ပ်လီကေးရှင်းတွင် ကြီးမားသောပြဿနာများကို ရင်ဆိုင်နိုင်သည်။
• max_standby_streaming_delay ကို တိုးမြှင့်မလား။ ဟုတ်ကဲ့၊ အစီရင်ခံစာတွေအတွက် ဒါက မှန်ပါတယ်။ သင့်တွင် သုံးနာရီကြာ အစီရင်ခံချက်တစ်ခုရှိပြီး ထပ်တူပွားမှုများကြောင့် ပျက်ကျသွားစေလိုလျှင် နှောင့်နှေးမှုကို တိုးမြှင့်လိုက်ပါ။ ရေရှည်အစီရင်ခံစာတစ်ခုသည် ယခုဒေတာဘေ့စ်သို့ရောက်ရှိနေသည့်ဒေတာကို မည်သည့်အခါမျှမလိုအပ်ပါ။ သင့်တွင် သုံးနာရီကြာလျှင် ၎င်းကို ဒေတာဟောင်းကာလတစ်ခုအတွက် လုပ်ဆောင်နေပါသည်။ သင့်အတွက်၊ သုံးနာရီနှောင့်နှေးခြင်း သို့မဟုတ် ခြောက်နာရီနှောင့်နှေးခြင်းရှိမရှိ ကွာခြားမှုရှိလာမည်မဟုတ်သော်လည်း သင်သည် အစီရင်ခံစာများကို အမြဲမပြတ်လက်ခံရရှိမည်ဖြစ်ပြီး ၎င်းတို့နှင့် ကျဆင်းသွားပါက မည်သည့်ပြဿနာမျှရှိမည်မဟုတ်ပေ။
• ပုံမှန်အားဖြင့်၊ အထူးသဖြင့် ပုံစံတူတစ်ခုပေါ်တွင် hot_standby_feedback ကိုဖွင့်ရန် သင်ဆုံးဖြတ်ပါက ပုံတူများပေါ်တွင် ကြာရှည်စွာဆက်ရှင်များကို ထိန်းချုပ်ရန် လိုအပ်ပါသည်။ ဘာမဆိုဖြစ်သွားနိုင်လို့ပါ။ တောင်းဆိုချက်များကို စမ်းသပ်နိုင်စေရန် ဤပုံစံတူကို ဆော့ဖ်ဝဲရေးသားသူအား ကျွန်ုပ်တို့ပေးခဲ့ပါသည်။ ရူးသွပ်တဲ့ တောင်းဆိုချက်တစ်ခုကို သူရေးခဲ့တယ်။ သူထုတ်ပြီး လက်ဖက်ရည်သောက်ဖို့ ထွက်သွားတော့ ဆရာကြီးဆီ သွားလိုက်တယ်။ သို့မဟုတ် ကျွန်ုပ်တို့သည် မှားယွင်းသော လျှောက်လွှာကို ထိုနေရာတွင် ထည့်ထားနိုင်သည်။ အခြေအနေတွေက အမျိုးမျိုး။ ပုံတူများဆိုင်ရာ ဆက်ရှင်များကို ဆရာကြီးကဲ့သို့ ဂရုတစိုက် စောင့်ကြည့်ရမည်ဖြစ်သည်။
• ပုံတူများပေါ်တွင် လျင်မြန်ပြီး ရှည်လျားသောမေးခွန်းများရှိပါက၊ ဤအခြေအနေတွင် ဝန်ကိုဖြန့်ဝေရန် ၎င်းတို့ကို ခွဲထုတ်ခြင်းက ပိုကောင်းပါသည်။ ဤသည်မှာ streaming_delay သို့ လင့်ခ်တစ်ခုဖြစ်သည်။ မြန်ဆန်သောသူများအတွက်၊ ပုံတူကူးယူမှုနှောင့်နှေးမှုအနည်းငယ်ရှိသော ပုံတူတစ်ခုရှိသည်။ ရေရှည်အစီရင်ခံခြင်းတောင်းဆိုမှုများအတွက်၊ 6 နာရီ သို့မဟုတ် တစ်နေ့လျှင် နောက်ကျနေနိုင်သော ပုံတူတစ်ခုရှိပါ။ ဒါက လုံးဝပုံမှန်အခြေအနေပါ။

ကျွန်ုပ်တို့သည် ထိုနည်းအတိုင်းပင် အကျိုးဆက်များကို ဖယ်ရှားပစ်သည်-

• ဖောင်းနေတဲ့ စားပွဲတွေ တွေ့တယ်။
• ပြီးတော့ ငါတို့နဲ့ အကိုက်ညီဆုံး အသင့်တော်ဆုံး tool နဲ့ ချုံ့တယ်။

ဒုတိယဇာတ်လမ်းက ဒီမှာပဲအဆုံးသတ်တယ်။ တတိယဇာတ်လမ်းကို ဆက်ကြည့်ရအောင်။

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

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

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

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

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

ရွှေ့ပြောင်းမှု အောင်မြင်သော်လည်း၊

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

ဤအရာသည် ကျွန်ုပ်တို့၏အသက်တာများကို တစ်ဖန်ပြန်ပျက်စီးစေသည့် ဖောင်းကားနေပြန်သည်။

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

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

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

• ထိုသို့သော ကြီးမားသော ရွှေ့ပြောင်းမှုများသည် အလိုအလျောက် ဖြစ်မလာပါ။ ၎င်းတို့သည် အမြဲတမ်း ထိန်းချုပ်နိုင်ရမည်။
• တတ်သိနားလည်သူမှ ကြီးကြပ်ကွပ်ကဲရန် လိုအပ်ပါသည်။ သင့်အဖွဲ့တွင် DBA ရှိပါက၊ DBA မှ ၎င်းကိုပြုလုပ်ခွင့်ပြုပါ။ သူ့အလုပ်။ မဟုတ်ပါက၊ အတွေ့အကြုံအရှိဆုံးလူကို ဒေတာဘေ့စ်များနှင့် မည်သို့လုပ်ဆောင်ရမည်နည်း။
• ကော်လံတစ်ခုအား အပ်ဒိတ်လုပ်ထားသော်လည်း၊ ဒေတာဘေ့စ်အစီအစဉ်အသစ်တစ်ခု၊ ကျွန်ုပ်တို့သည် အပလီကေးရှင်း၏ဗားရှင်းအသစ်မထုတ်မီတွင် အဆင့်များအထိ အမြဲပြင်ဆင်နေပါသည်။
• မွမ်းမံထားသော ဒေတာကို မှတ်တမ်းတင်မည့် အကွက်အသစ်များကို ထည့်သွင်းထားသည်။
• ကျွန်ုပ်တို့သည် အကွက်ဟောင်းမှ ဒေတာကို အပိုင်းငယ်ဖြင့် အကွက်အသစ်သို့ လွှဲပြောင်းပေးပါသည်။ ငါတို့ဘာလို့ဒီလိုလုပ်တာလဲ။ ပထမဦးစွာ ကျွန်ုပ်တို့သည် ဤလုပ်ငန်းစဉ်၏ လုပ်ငန်းစဉ်ကို အမြဲထိန်းချုပ်ပါသည်။ အစုအဝေးတွေ အများကြီး လွှဲပြောင်းပြီးပြီဆိုတာ ငါတို့သိပြီး ငါတို့မှာ အများကြီးကျန်သေးတယ်။
• ဒုတိယအပြုသဘောဆောင်သောအကျိုးသက်ရောက်မှုသည်ထိုကဲ့သို့သောအသုတ်တစ်ခုစီကြားတွင်ကျွန်ုပ်တို့သည်အရောင်းအ ၀ ယ်ကိုပိတ်သည်၊ အသစ်တစ်ခုဖွင့်ပြီး၎င်းသည်ပန်းကန်ပြားအတိုင်းအလုပ်လုပ်ရန် autovacuum ကိုခွင့်ပြုသည်၊ ပြန်လည်အသုံးပြုရန်အတွက် dead line ကိုအမှတ်အသားပြုခြင်းဖြစ်သည်။
• အပလီကေးရှင်းလည်ပတ်နေချိန်တွင် ပေါ်လာမည့်စာကြောင်းများ (ကျွန်ုပ်တို့၌ အပလီကေးရှင်းဟောင်းကို လည်ပတ်နေပါသည်)၊ ကွက်လပ်အသစ်များသို့ တန်ဖိုးအသစ်များရေးမည့် အစပျိုးတစ်ခုကို ပေါင်းထည့်ပါသည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ၎င်းသည် အဟောင်းတန်ဖိုး၏ တစ်ရာဖြင့် မြှောက်ခြင်းဖြစ်သည်။
• အကယ်၍ ကျွန်ုပ်တို့သည် လုံးဝခေါင်းမာပြီး တူညီသောအကွက်ကို လိုချင်ပါက၊ ရွှေ့ပြောင်းခြင်းအားလုံးပြီးမြောက်ပြီး အပလီကေးရှင်း၏ဗားရှင်းအသစ်ကို မထုတ်ပြန်မီတွင်၊ ကျွန်ုပ်တို့သည် အကွက်များကို ရိုးရိုးအမည်ပြောင်းပါ။ အဟောင်းများကို တီထွင်ပြီး အချို့သောအမည်များပေးကြပြီး နယ်ပယ်အသစ်များကို အဟောင်းများဟု အမည်ပြောင်းကြသည်။
• ထို့နောက်မှသာ ကျွန်ုပ်တို့သည် အပလီကေးရှင်း၏ ဗားရှင်းအသစ်ကို စတင်လိုက်ပါသည်။

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

ဤတွင် တတိယဇာတ်လမ်း ပြီးဆုံးသည်။

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

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

bloat ကိုမရှာဖွေမီ၊ သင်သည် extension ကိုထည့်သွင်းရပါမည်။ pgstattuple.

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

• ပထမတစ်ခုသည်အလုပ်လုပ်ရန်အတော်လေးအချိန်ကြာမြင့်သော်လည်း၊ ၎င်းသည်သင့်အားဇယားမှအတိအကျ bloat တန်ဖိုးများကိုပြသလိမ့်မည်။
• ဒုတိယတစ်မျိုးက ဇယားအတိုင်း ဖောင်းခြင်းရှိ၊မရှိ မြန်မြန်အကဲဖြတ်ဖို့ လိုအပ်တဲ့အခါ ပိုမြန်ပြီး အလွန်ထိရောက်ပါတယ်။ ပြီးတော့ ဖောင်းတာက Postgres ဇယားထဲမှာ အမြဲရှိနေတယ်ဆိုတာလည်း နားလည်ထားသင့်ပါတယ်။ ၎င်းသည် ၎င်း၏ MVCC မော်ဒယ်၏ အင်္ဂါရပ်တစ်ခုဖြစ်သည်။
• နှင့် 20% bloat သည် ကိစ္စအများစုတွင် ဇယားများအတွက် ပုံမှန်ဖြစ်သည်။ ဆိုလိုသည်မှာ သင်သည် ဤဇယားကို ဖိသိပ်၍ မစိုးရိမ်သင့်ပါ။

အသုံးမဝင်သောဒေတာများဖြင့် ရောင်နေသော ဇယားများကို မည်သို့ခွဲခြားသတ်မှတ်ရမည်ကို ကျွန်ုပ်တို့ ရှာဖွေတွေ့ရှိခဲ့သည်။

ယခု bloat ကိုဖြေရှင်းနည်းအကြောင်း။

• အကယ်၍ ကျွန်ုပ်တို့တွင် တက်ဘလက်ငယ်နှင့် ကောင်းသောဒစ်များရှိသည်ဆိုပါက၊ ဆိုလိုသည်မှာ၊ တက်ဘလက်တစ်လုံးတွင် gigabyte အထိရှိပါက VACUUM FULL ကိုသုံးရန်အတော်လေးဖြစ်နိုင်သည်။ သူသည် သင့်ထံမှ သီးသန့်သော့ကို စားပွဲပေါ်မှ စက္ကန့်အနည်းငယ်ကြာအောင် ယူပြီး အဆင်ပြေသော်လည်း အရာအားလုံးကို မြန်မြန်ဆန်ဆန် ကြမ်းကြမ်းတမ်းတမ်း လုပ်လိမ့်မည်။ VACUUM FULL က ဘာလုပ်သလဲ။ ၎င်းသည် စားပွဲပေါ်တွင် သီးသန့်သော့ခတ်ယူကာ ဇယားဟောင်းများမှ စားပွဲအသစ်သို့ တိုက်ရိုက်အတန်းများကို ပြန်လည်ရေးသားသည်။ အဆုံးမှာ သူတို့ကို အစားထိုးတယ်။ ၎င်းသည် ဖိုင်ဟောင်းများကို ဖျက်ပြီး အဟောင်းများကို အသစ်များဖြင့် အစားထိုးသည်။ သို့သော်၎င်း၏အလုပ်၏ကြာချိန်အတွက်၎င်းသည်စားပွဲပေါ်တွင်သီးသန့်သော့ခတ်ယူသည်။ ဆိုလိုသည်မှာ ဤဇယားကို သင်ဘာမျှ မလုပ်နိုင်၊ ၎င်းကို စာမရေးဘဲ၊ မဖတ်ဘဲ၊ ၎င်းကို မပြင်နိုင်ဟု ဆိုလိုသည်။ နှင့် VACUUM FULL သည် အချက်အလက်ရေးရန် နောက်ထပ် disk space လိုအပ်သည်။
• နောက်တစ်ခု pg_repack. ၎င်း၏မူအရ၊ ၎င်းသည် VACUUM FULL နှင့် အလွန်ဆင်တူသည်၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် ဖိုင်ဟောင်းများမှ အချက်အလက်အသစ်များကို ပြန်လည်ရေးသားပြီး ဇယားတွင် အစားထိုးပေးသောကြောင့်ဖြစ်သည်။ သို့သော် တစ်ချိန်တည်းမှာပင်၊ ၎င်းသည် ၎င်း၏အလုပ်အစတွင် စားပွဲပေါ်တွင် သီးသန့်သော့ခတ်ထားခြင်းကို မယူဘဲ၊ ဖိုင်များကို အစားထိုးရန်အတွက် ဒေတာအဆင်သင့်ရှိပြီးသားအချိန်တွင်သာ ၎င်းကို ယူဆောင်သွားမည်ဖြစ်သည်။ ၎င်း၏ disk အရင်းအမြစ်လိုအပ်ချက်များသည် VACUUM FULL နှင့် ဆင်တူသည်။ သင်သည် အပိုဒစ်နေရာလွတ် လိုအပ်ပြီး သင့်တွင် terabyte ဇယားများရှိလျှင် ၎င်းသည် တစ်ခါတစ်ရံတွင် အရေးကြီးပါသည်။ ၎င်းသည် I/O နှင့်တက်ကြွစွာအလုပ်လုပ်သောကြောင့်၎င်းသည်ပရိုဆက်ဆာကိုအတော်လေးဆာလောင်နေပါသည်။
• တတိယ အသုံးဝင်ပုံကတော့ pgcompactable. အနည်းငယ်ကွဲပြားသောအခြေခံမူများနှင့်အညီအလုပ်လုပ်သောကြောင့်အရင်းအမြစ်များကိုပိုမိုသတိထားပါ။ pgcompacttable ၏ အဓိက အယူအဆမှာ ၎င်းသည် ဇယားရှိ အပ်ဒိတ်များကို အသုံးပြု၍ တိုက်ရိုက် အတန်းအားလုံးကို ဇယား၏ အစသို့ ရွှေ့ပေးခြင်းဖြစ်သည်။ ကျွန်ုပ်တို့တွင် အစပိုင်းနှင့် အဆုံးတွင် အတန်းသေများရှိသည်ကို ကျွန်ုပ်တို့သိသောကြောင့် ဤစားပွဲပေါ်တွင် လေဟာနယ်တစ်ခုလည်ပတ်နေပါသည်။ ပြီးတော့ လေဟာနယ်ကိုယ်တိုင်က ဒီအမြီးကို ဖြတ်ပစ်လိုက်တယ်၊ ဥပမာ၊ နောက်ထပ် disk space အများကြီး မလိုအပ်ပါဘူး။ တစ်ချိန်တည်းမှာပင်၊ ၎င်းကို အရင်းအမြစ်များ အရ ညှစ်ထုတ်နိုင်သည်။

အရာအားလုံးကိရိယာများနှင့်အတူ။

အတွင်းပိုင်းကိုပိုမိုလေ့လာခြင်းနှင့်ပတ်သက်၍ စိတ်ဝင်စားဖွယ်ကောင်းသော bloat topic ကိုတွေ့ပါက၊ ဤနေရာတွင် အသုံးဝင်သောလင့်ခ်အချို့ရှိပါသည်။

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - ဒါက ကျွန်တော့်လုပ်ဖော်ကိုင်ဖက်ဆီက အစီရင်ခံစာပါ။ ယေဘုယျအားဖြင့် Postgres ၏နေရာသည် ၎င်း၏အလုပ်နှင့်ဘဝအတွင်း သွားနေသည့်နေရာဖြစ်သည်။ ထို့အပြင် bloat နှင့်ပတ်သက်သောဒေတာဘေ့စ်စီမံခန့်ခွဲသူများအတွက်အလွန်ကြီးမားပြီးအသေးစိတ်နည်းပညာပိုင်းဆိုင်ရာအပိုင်းတစ်ခုရှိသည်။
• https://github.com/dataegret/pg-utils - ဤသည်မှာ ဒေတာဘေ့စ်၏အခြေအနေကို စစ်ဆေးရန်အတွက် အသုံးဝင်သော script အများအပြားကို သိမ်းဆည်းထားသည့် ကျွန်ုပ်တို့၏ repository သို့ လင့်ခ်တစ်ခုဖြစ်သည်။ ဤနေရာတွင် bloat ကိုရှာဖွေရန် script များကိုသင်ရှာနိုင်သည်။
• တတိယ и စတုတ္ထ ဆိုင်းဘုတ်များကို ကျုံ့ရန် ကူညီပေးမည့် ကိရိယာများနှင့် ချိတ်ဆက်မှုများ။
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - ဒါက ကျွန်တော့်လုပ်ဖော်ကိုင်ဖက်ဆီက ပို့စ်တစ်ခုပါ။ အဲဒီမှာ သူတော်တော်လေးလေးနက်ပြီး နည်းပညာပိုင်းအရ အက်ဒမင်တွေနဲ့ နီးစပ်တဲ့အဆင့်မှာ ဖောင်းတာကို အသေးစိတ်ခွဲခြမ်းစိတ်ဖြာတယ်။

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

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

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

ဤကိစ္စတွင်၊ ၎င်းသည် DBA အတွက် မလိုအပ်ဘဲ သင့်ကုမ္ပဏီ၏ စီမံခန့်ခွဲသူများအတွက် အလုပ်ဖြစ်သည်။

ကျွန်တော်က အက်ဒမင်တစ်ယောက်ပါ။

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

ငါဝင်လာပြီး 5 မိနစ်တိုင်းကြည့်ရမှာလား။

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

ဒီလိုဖြစ်ရတဲ့ အကြောင်းရင်းတွေက ရှင်းရှင်းလင်းလင်းရှိပါသလား။

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

အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ pg_repack utility အကြောင်းကို ရှင်းပြချင်ပါတယ်။ သီးသန့်သော့ခတ်မထားရင်...

သူမသည် သီးသန့်သော့ခတ်ထားသည်။

... ဒါမှ ဒေတာတွေ ဆုံးရှုံးသွားနိုင်တယ်။ ကျွန်ုပ်၏လျှောက်လွှာသည် ဤကာလအတွင်း မည်သည့်အရာကိုမျှ မှတ်တမ်းတင်မထားသင့်ပါ။

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

ဆိုလိုတာက သူတကယ်ပဲ အဆုံးစွန်ထိ လုပ်နေတာလား။

အဆုံးတွင်၊ ဤဖိုင်များကို လဲလှယ်ရန် သီးသန့်သော့ကို ယူသည်။

VACUUM FULL ထက် ပိုမြန်မှာလား။

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

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

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

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

မည်သည့်ကိစ္စတွင်မဆို လိုင်းတစ်ခုလုံးကို ထိုနေရာတွင် မွမ်းမံထားသည်။ Postgres တွင် ဒေတာသိုလှောင်မှု ပုံစံနှစ်မျိုးရှိသည်။ ၎င်းသည် ဒေတာအမျိုးအစားမှ ရွေးချယ်သည်။ ဇယားတွင် တိုက်ရိုက် သိမ်းဆည်းထားသည့် ဒေတာများ ရှိပြီး Tos data လည်း ရှိပါသည်။ ဤအရာများသည် ကြီးမားသောဒေတာများဖြစ်သည်- text၊ json။ ၎င်းတို့ကို သီးခြားပန်းကန်ပြားများတွင် သိမ်းဆည်းထားသည်။ ဤတက်ဘလက်များ အရ၊ ဖောင်းပွခြင်းနှင့် တူညီသော ဇာတ်လမ်း ဖြစ်ပေါ်လာသည်၊ ဆိုလိုသည်မှာ အရာအားလုံးသည် အတူတူပင် ဖြစ်သည်။ ၎င်းတို့ကို သီးခြားစီ စာရင်းပေးထားသည်။

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

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

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

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

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

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

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

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

ဥပမာအားဖြင့်၊ DBA သည် လက်ဖက်ရည်သောက်ရန်၊ အပန်းဖြေစခန်းတစ်ခုတွင် ရှိနေသည် စသည်တို့ဖြစ်သည်။

ဖိုင်စနစ်တစ်ခုကို ဖန်တီးသောအခါ၊ ဒေတာမရေးရသေးသော အနည်းဆုံး အရန်နေရာအချို့ကို ဖန်တီးထားသည်။

လုံးဝ သုညအောက် ဖြစ်နေရင် ဘယ်လိုလုပ်မလဲ။

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

အခြားကိရိယာများ ရှိပါသလား။

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

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

သူတို့လည်း ထုပ်ပိုးကြတယ်။

သို့သော် လေဟာနယ်သည် အညွှန်းကိန်းကို မထိခိုက်စေပါ။

တချို့က အညွှန်းတစ်ခုနဲ့ အလုပ်လုပ်တယ်။ ဥပမာ pg_rapack, pgcompacttable။ လေဟာနယ်သည် အညွှန်းများကို ပြန်လည်ဖန်တီးပြီး ၎င်းတို့ကို အကျိုးသက်ရောက်စေသည်။ VACUUM FULL ဖြင့် အရာအားလုံးကို ထပ်ရေးရန် စိတ်ကူးဖြစ်သည်၊ ဆိုလိုသည်မှာ လူတိုင်းနှင့် အဆင်ပြေသည်။

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

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

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

ဒါက ဝန်ဆောင်မှုတစ်ခုပါ။ Okmeter.

ဒါက စီးပွားဖြစ်ထုတ်ကုန်လား။

ဟုတ်ကဲ့။ ဒါက စီးပွားဖြစ်ထုတ်ကုန်တစ်ခုပါ။

source: www.habr.com