Kubernetes- CPU ကန့်သတ်ချက်များကို ဖယ်ရှားခြင်းဖြင့် သင့်ဝန်ဆောင်မှုများကို အရှိန်မြှင့်ပါ။

2016 တွင်ကျွန်ုပ်တို့သည် Buffer တွင်ရှိသည်။ Kubernetes သို့ပြောင်းခဲ့သည်။ယခုအချိန်တွင် node 60 ခန့် (AWS) နှင့် 1500 containers သည် ကျွန်ုပ်တို့၏ k8s အစုအဝေးတွင် အလုပ်လုပ်နေပါသည်။ ကန်တယ်။. သို့သော်၊ ကျွန်ုပ်တို့သည် အစမ်းသုံးခြင်းနှင့် အမှားအယွင်းများမှတစ်ဆင့် microservices သို့ ပြောင်းရွှေ့ခဲ့ပြီး k8s နှင့် နှစ်အတော်ကြာကြာ အလုပ်လုပ်ပြီးနောက်တွင်ပင် ပြဿနာအသစ်များနှင့် ရင်ဆိုင်နေကြရဆဲဖြစ်သည်။ ဒီ post မှာ ကျွန်တော်ပြောမယ့် အကြောင်းအရာ ပရိုဆက်ဆာကန့်သတ်ချက်များ: သူတို့ဟာ အလေ့အကျင့်ကောင်းတွေလို့ ငါတို့ဘာလို့ထင်ခဲ့ကြပြီး ဘာကြောင့် ဒီလောက်တောင် မကောင်းခဲ့ကြတာလဲ။

ပရိုဆက်ဆာ ကန့်သတ်ချက်များနှင့် အဟန့်အတားများ

အခြားသော Kubernetes အသုံးပြုသူများကဲ့သို့၊ Google သည် CPU ကန့်သတ်ချက်များကို သတ်မှတ်ရန် အထူးအကြံပြုထားသည်။. ထိုသို့သောဆက်တင်မရှိဘဲ၊ node တစ်ခုရှိကွန်တိန်နာများသည် ပရိုဆက်ဆာပါဝါအားလုံးကိုယူနိုင်ပြီး၊ ၎င်းသည် အရေးကြီးသော Kubernetes လုပ်ငန်းစဉ်များကိုဖြစ်ပေါ်စေသည် (ဥပမာ၊ kubelet) တောင်းဆိုချက်များကို တုံ့ပြန်မှု ရပ်သွားပါမည်။ ထို့ကြောင့်၊ CPU ကန့်သတ်ချက်များသတ်မှတ်ခြင်းသည် သင့် node များကိုကာကွယ်ရန် နည်းလမ်းကောင်းတစ်ခုဖြစ်သည်။

ပရိုဆက်ဆာ ကန့်သတ်ချက်များသည် ကွန်တိန်နာကို သတ်မှတ်ထားသော ကာလတစ်ခုအတွက် အသုံးပြုနိုင်သည့် အများဆုံး CPU အချိန် (မူလ 100ms) ဖြစ်ပြီး ကွန်တိန်နာသည် ဤကန့်သတ်ချက်ထက် ဘယ်တော့မှ ကျော်လွန်မည်မဟုတ်ပါ။ Kubernetes အတွက် throttling ကွန်တိန်နာကန့်သတ်ချက်ထက်ကျော်လွန်ခြင်းမှကာကွယ်ရန်အထူးကိရိယာကိုအသုံးပြုသည်။ CFS ခွဲတမ်းဒါပေမယ့် ဒီ CPU အတု ကန့်သတ်ချက်တွေက စွမ်းဆောင်ရည်ကို ထိခိုက်စေပြီး သင့်ကွန်တိန်နာတွေရဲ့ တုံ့ပြန်မှုအချိန်ကို တိုးစေပါတယ်။

ပရိုဆက်ဆာကန့်သတ်ချက်များကို မသတ်မှတ်ပါက ဘာဖြစ်နိုင်သနည်း။

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

အဟန့်အတားနှင့် တုံ့ပြန်မှုပြဿနာ၏ ထင်ရှားခြင်း။

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

အောက်တွင်သင်တွေ့မြင်နိုင်သည်အတိုင်း၊ ကျွန်ုပ်တို့သည်ကန့်သတ်ချက်ကိုသတ်မှတ်ထားသည်။ 800m (0.8 သို့မဟုတ် 80% core) နှင့် အထွတ်အထိပ်တန်ဖိုးများကို အကောင်းဆုံးရောက်ရှိနိုင်သည်။ 200m (20% core)။ ဝန်ဆောင်မှုကို တားဆီးခြင်းမပြုမီ ကျွန်ုပ်တို့တွင် ပရိုဆက်ဆာပါဝါများစွာ ကျန်ရှိနေသေးသည်ဟု ထင်ရသော်လည်း ...

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

ဒါကို ရင်ဆိုင်ပြီး မကြာခင်မှာ အရင်းအမြစ်များစွာကို ရှာဖွေတွေ့ရှိခဲ့ပါတယ် (github တွင်ပြဿနာ, zadano တွင်တင်ပြခြင်း။, omio မှာတင်ပါ။) အဟန့်အတားကြောင့် ဝန်ဆောင်မှုများ၏ စွမ်းဆောင်ရည်ကျဆင်းမှုနှင့် တုံ့ပြန်မှုအချိန်နှင့် ပတ်သက်၍

CPU load နည်းပါးချိန်တွင် အဟန့်အတားကို ကျွန်ုပ်တို့ အဘယ်ကြောင့် တွေ့မြင်ရသနည်း။ အတိုချုံးဗားရှင်းမှာ - "သတ်မှတ်ထားသော ပရိုဆက်ဆာကန့်သတ်ချက်များဖြင့် ကွန်တိန်နာများကို မလိုအပ်ဘဲ အဟန့်အတားဖြစ်စေသည့် Linux kernel တွင် ချွတ်ယွင်းချက်တစ်ခုရှိနေပါသည်။" ပြဿနာရဲ့ သဘောသဘာဝကို စိတ်ဝင်စားရင် တင်ပြချက်ကို ဖတ်ရှုနိုင်ပါတယ် (видео и စာသား Dave Chiluk မှရွေးချယ်မှုများ။

CPU ကန့်သတ်ချက်များကို ဖယ်ရှားခြင်း (အလွန်သတိထား၍)

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

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

အရေးတကြီးကိစ္စရပ်တွင် စီးပွားရေးစာပေးစာယူ။

ကန့်သတ်ချက်များကို ရုတ်သိမ်းသည့်အခါ သင့် node များကို မည်သို့ကာကွယ်မည်နည်း။

"ကန့်သတ်မထားသော" ဝန်ဆောင်မှုများကို သီးခြားခွဲထုတ်ခြင်း-

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

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

မှန်ကန်သော ပရိုဆက်ဆာနှင့် မန်မိုရီတောင်းဆိုမှုကို သတ်မှတ်ပေးခြင်း-

ကျွန်ုပ်တို့၏အကြီးမားဆုံးကြောက်ရွံ့မှုမှာ လုပ်ငန်းစဉ်သည် အရင်းအမြစ်များစွာကို သုံးစွဲပြီး တောင်းဆိုမှုများကို တုံ့ပြန်မှုရပ်တန့်သွားခြင်းပင်ဖြစ်သည်။ ယခုအချိန်မှစ၍ (Datadog မှကျေးဇူးတင်စကား) ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏အစုအဝေးရှိ ဝန်ဆောင်မှုအားလုံးကို ရှင်းရှင်းလင်းလင်း စောင့်ကြည့်နိုင်ခဲ့ပြီး၊ ကျွန်ုပ်တို့သည် "မသက်ဆိုင်သော" အဖြစ်သတ်မှတ်ရန် စီစဉ်ထားသော လပေါင်းများစွာ၏ လုပ်ဆောင်ချက်များကို ပိုင်းခြားစိတ်ဖြာခဲ့ပါသည်။ ကျွန်ုပ်သည် အမြင့်ဆုံး CPU အသုံးပြုမှုကို အနားသတ် 20% ဖြင့် သတ်မှတ်ပြီး k8s သည် အခြားဝန်ဆောင်မှုများကို node တွင် တာဝန်ပေးရန် ကြိုးစားသောအခါတွင် node တွင် space ခွဲဝေပေးပါသည်။

ဂရပ်တွင် သင်မြင်ရသည့်အတိုင်း၊ ပရိုဆက်ဆာပေါ်ရှိ အမြင့်ဆုံးဝန်ကို ရောက်ရှိသွားပါပြီ။ 242m CPU Cores (0.242 ပရိုဆက်ဆာ cores)။ ပရိုဆက်ဆာ တောင်းဆိုချက်တစ်ခုအတွက်၊ ဤတန်ဖိုးထက် အနည်းငယ်ပိုကြီးသော နံပါတ်တစ်ခုကို ယူရန် လုံလောက်ပါသည်။ ဝန်ဆောင်မှုများသည် သုံးစွဲသူဗဟိုပြုဖြစ်သောကြောင့် အမြင့်ဆုံး load တန်ဖိုးများသည် အသွားအလာနှင့် တိုက်ဆိုင်နေကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။

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

minuses များထဲမှ၊ ကျွန်ုပ်တို့သည် "ရှုံးခဲ့သည်"ကွန်တိန်နာသိပ်သည်းဆ", i.e. node တစ်ခုတွင် အလုပ်လုပ်သော container အရေအတွက်။ ကျွန်ုပ်တို့သည် အသွားအလာသိပ်သည်းဆနည်းသောနေရာတွင် "အပန်းဖြေခြင်း" အများအပြားရှိနိုင်ပြီး၊ သင်သည် မြင့်မားသောပရိုဆက်ဆာဝန်ကိုရောက်ရှိရန် အခွင့်အလမ်းလည်းရှိနိုင်သည်၊ သို့သော် autoscaling node များသည် နောက်ဆုံးတွင် ကူညီပေးသင့်ပါသည်။

ရလဒ်များကို

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

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ပင်မစာမျက်နှာတွင် အကောင်းဆုံးရလဒ်များကို ရရှိခဲ့သည် (buffer.com) အဲဒီမှာ ဝန်ဆောင်မှု အရှိန်မြှင့်လာတယ်။ နှစ်ဆယ့်နှစ်ခါ!

Linux kernel bug ကို fixed ဖြစ်ပါသလား။

ဟုတ်ပါတယ်, ချွတ်ယွင်းချက်ကို ပြုပြင်ပြီးဖြစ်ကာ ပြုပြင်မှုကို kernel တွင် ထည့်သွင်းထားသည်။ ဖြန့်ချိမှုဗားရှင်း 4.19 နှင့်အထက်။

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

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

• Debian- ဖြန့်ဖြူးမှု၏ နောက်ဆုံးဗားရှင်းသို့ ပေါင်းစည်းထားသည့် ပြင်ဆင်ချက်၊ မင်္ဂလာပါ၊ တော်တော်လန်းတယ် (သြဂုတ်လ 2020) ယခင်ဗားရှင်းအချို့ကိုလည်း ပြင်ဆင်နိုင်သည်။
• Ubuntu- နောက်ဆုံးဗားရှင်းသို့ ပေါင်းစည်းထားသော ပြင်ဆင်ချက် Ubuntu Focal Fossa 20.04
• EKS တွင် ပြုပြင်မှုတစ်ခုရရှိပါသည်။ ဒီဇင်ဘာလ 2019 ခုနှစ်. သင့်ဗားရှင်းထက်နိမ့်ပါက၊ သင်သည် AMI ကို အပ်ဒိတ်လုပ်သင့်သည်။
• kops- ဇွန်လ 2020 မှ у kops 1.18+ ပင်မ host ပုံသည် Ubuntu 20.04 ဖြစ်လိမ့်မည်။ သင်၏ kops ဗားရှင်းသည် ဟောင်းနေပါက၊ ပြင်ဆင်ရန် စောင့်ရပေမည်။ ငါတို့ကိုယ်တိုင် အခုစောင့်နေတယ်။
• GKE (Google Cloud)- ပေါင်းစပ်ပြင်ဆင်ပါ။ ဇန်နဝါရီလ 2020 ခုနှစ်ဒါပေမယ့် throttling နဲ့ ပတ်သက်ပြီး ပြဿနာရှိပါတယ်။ စောင့်ကြည့်နေကြဆဲဖြစ်သည်။.

ပြုပြင်မှုသည် throttling ပြဿနာကိုဖြေရှင်းပါက ဘာလုပ်ရမည်နည်း။

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

ကောက်ချက်

• အကယ်၍ သင်သည် Linux အောက်တွင် Docker ကွန်တိန်နာများနှင့် အလုပ်လုပ်ပါက ( Kubernetes၊ Mesos၊ Swarm သို့မဟုတ် အခြားမည်သည့်ကိစ္စမဆို)၊ သင်၏ကွန်တိန်နာများကို ပိတ်ဆို့ခြင်းများကြောင့် စွမ်းဆောင်ရည် ဆုံးရှုံးသွားနိုင်သည်။
• ချွတ်ယွင်းချက်ကို ပြင်ပြီးပြီဟု မျှော်လင့်ခြင်းဖြင့် သင်၏ဖြန့်ဖြူးမှု၏ နောက်ဆုံးဗားရှင်းသို့ အပ်ဒိတ်လုပ်ကြည့်ပါ။
• ပရိုဆက်ဆာကန့်သတ်ချက်များကို ဖယ်ရှားခြင်းသည် ပြဿနာကိုဖြေရှင်းနိုင်သော်လည်း ၎င်းသည် အလွန်သတိထား၍အသုံးပြုသင့်သည့် အန္တရာယ်ရှိသောနည်းပညာတစ်ခုဖြစ်သည် ( kernel ကို ဦးစွာမွမ်းမံပြီး ရလဒ်များကို နှိုင်းယှဉ်ပါက ပိုကောင်းသည် )
• အကယ်၍ သင်သည် CPU ကန့်သတ်ချက်များကို ဖယ်ရှားပြီးပါက၊ သင်၏ CPU နှင့် မမ်မိုရီအသုံးပြုမှုကို ဂရုတစိုက်စောင့်ကြည့်ပြီး သင်၏ CPU အရင်းအမြစ်များသည် သင်၏သုံးစွဲမှုထက် ကျော်လွန်နေကြောင်း သေချာပါစေ။
• လုံခြုံသောရွေးချယ်မှုတစ်ခုသည် ဟာ့ဒ်ဝဲဝန်ဆောင်မှုမြင့်မားသောအခါတွင် ပေါ့ဒ်အသစ်များဖန်တီးရန် အလိုအလျောက်စကေးချရန် ရွေးချယ်စရာဖြစ်ပြီး kubernetes သည် ၎င်းတို့အား အခမဲ့ node များအဖြစ် သတ်မှတ်ပေးမည်ဖြစ်သည်။

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

PS ဒါဟာဖြစ်ပါတယ် စာရေးသူသည် စာဖတ်သူများနှင့် မှတ်ချက်ပေးသူများ (အင်္ဂလိပ်လို) နှင့် သက်ဆိုင်ပါသည်။


source: www.habr.com