Harmony in Performance Monitoring

Performance Monitoring လုပ်တဲ့အခါ CPU/RAM/IO/Storage/Network တွေအပြင် Temperature နဲ့ Power Consumption တွေကိုပါ Monitor လုပ်ထားသင့်ပါတယ်။

အထူးသဖြင့် CPU ရဲ့ Power Consumption နဲ့ Temperature တွေဟာ Harmony ဖြစ်နေရမှာပါ။ အဲ့လိုပဲ Storage ကိုယူသုံးတဲ့ Server/App တွေတင်ထားတဲ့ Server တွေပေါ်မှာဆိုရင်လည်း I/O Rate နဲ့တကွ Storage ရဲ့ Temperature ကလည်း အနည်းနဲ့အများ ဆင်တူတဲ့ Graph တွေအနေနဲ့ ပေါ်နေရမှာပါ။ နောက်ဘာကျန်သေးလဲ? Network Utilization ဖြစ်ပါတယ်။ သူလည်း ထိုနည်းလည်းကောင်းပဲ… Data Input လာတယ်ဆိုတာ များသောအားဖြင့် Network Interface တွေကနေ ဝင်လာတာပါ။ ဥပမာ Website Visitor တွေ၊ API Call တွေ၊ Database Query တွေ၊ Data Synchronization တွေ စသည်ဖြင့်ပေါ့။

Network Utilization ပါးပါးနဲ့ CPU Spike ကြီးကြီးလား ဒါဆိုရင် Processing များတဲ့ လက္ခဏာတစ်ခုပါ။ Network Utilization အသင့်အတင့်နဲ့ I/O Rate (Write) များများလား – ဒါဆိုရင်တော့ File Store လာလုပ်တာဖြစ်နိုင်မယ့် လက္ခဏာတစ်ခုပေါ့။

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

နောက်ပြီး တချက် တချက် Spike ပဲလား။ ဒါမှမဟုတ် ဆက်တိုက်ကြီး မြင့်တက်လာနေတဲ့ Load ဖြစ်နေမလား။ ဆက်တိုက်ကြီးမြင့်နေတဲ့ Load ဆိုရင် Data Input နဲ့ Output နဲ့က ပုံမှန် High ဖြစ်နေရမယ်။ အကယ်၍ Web Server နဲ့ Website/API သုံးထားရင် Request/Response Log တွေ အဲ့အချိန်မှာ များရမယ်။ Database Server ဆိုလည်း Query တွေရှိရမယ်။ အဲ့လို Data Input Log တွေ (Web Server Log/Database Query Log, etc) က များနေရမယ်။ မဟုတ်ပဲ Data Input Log တွေက ထင်သလောက်မများပဲ နည်းနေမယ်ဆိုရင်တော့ Processing Time ကြာတဲ့ ပုံမျိုးရှိမယ်။ အဲဒါဆိုရင်တော့ နည်းနည်းထပ်ပြီး Investigate လုပ်စရာတွေပေါ်လာမယ်။ အဲ့လို Processing Time ကြာတဲ့ Request တွေ ခုထက်ပိုများပြီး ဝင်လာမယ်ဆိုရင် System က ခံနိုင်ပါ့မလား၊ App နဲ့ Client တွေရဲ့ Nature က အဲ့လိုဖြစ်နေတာလား ဒါမှမဟုတ် Configuration မှားနေတာလား။ Nature ကိုယ်တိုင်ကိုက အက်လိုဖြစ်နေရင်တော့ သက်ဆိုင်ရာ Dev တွေကို Report လုပ်ပေးသင့်တယ်။ ဒါမှမဟုတ် Configuration မှားတာ (ဥပမာ Request Time out ရဲ့ Limit များနေတာ) ဆိုရင်တော့ သက်ဆိုင်ရာ Team တွေနဲ့ တိုင်ပင်ပြီး Optimization ပြန်လုပ်ပေးသင့်ပါတယ်။

ပုံမှာကတော့ Client Site တစ်ခုမှာ Monitor ထောက်ထားတာလေးပါ။ Power Consumption ကတော့ KmW အနေနဲ့ပြနေတယ်။ ပြောရရင် လွဲတော့မလွဲပေမယ့် Unit မှာ ပုံမှန်မဟုတ်တာဖြစ်နေတာပေါ့။ K ကတော့ Kilo (10^3) နဲ့ m ကတော့ Milli (10^-3) ရယ် W ကတော့ Watt ပါ။ အဲဒါကကျ ဘယ်လိုဖြစ်လာလဲဆိုတော့ တကယ့် Data Source ကနေ milli-Watt အနေနဲ့ Data ဝင်တာပါ။ အဲဒါက ထောင်ကျော်တဲ့ Data ဝင်လာတော့ Zabbix ကနေ အလိုလျောက် Kilo ထဲ ထည့်ပလိုက်တာ။ အဲ့တော့ K နဲ m က ကျေသွားတယ်။ တကယ့် Unit အစစ်ကတော့ Watt ပါပဲ။

—

နိဂုံး

တကယ်တော့ Graph တွေ ထိုင်ကြည့်တာရဲ့နောက်ကွယ်မှာ ဖြာထွက်နေသင့်တဲ့ Thinking တွေကတော့ အများကြီးရှိနေမှ တကယ် Respond ကောင်းကောင်းပြန်လုပ်နိုင်မှာပါ။ နေရာတိုင်း ကျွန်တော် အထက်က ပြောခဲ့သလို ဒီပုံစံပဲ တွေးရမှာလားဆိုတော့ မဟုတ်ပါဘူး။ ကိုယ့် Work Environment တွေ Server Environment တွေ၊ App Nature တွေ နဲ့ ကိုက်မယ့် Thinking မျိုးတွေ တကယ်လိုအပ်ပါတယ်လို့ ရေးသားရင်း Performance Monitoring နဲ့ပတ်သက်တဲ့ Knowledge တစ်ခု Share ပေးလိုက်ပါတယ်။

စာကြွင်း။ ။ ဆိုတော့ Monitoring လုပ်တဲ့သူဟာလည်း ကိုယ့် Infra/Server/App စတဲ့ Nature တွေ Environment တွေကိုလည်း ကောင်းကောင်းသိနေမှ ပေါ်လာတဲ့ အချက်အလက်တွေကို Correlate လုပ်နိုင်ပြီး Issue တစ်ခုခုရှိရင် Pin-Point ဖြေရှင်းပေးနိုင်မှာပဲ မဟုတ်ပါလား။

With Love –