Server များကို အေးစေခဲ့သော Swap File မရှိခြင်း

စက်တင်ဘာ ၂၄ တွင် production server တစ်ခုသည် တုံ့ပြန်ခြင်း ရပ်သွားခဲ့သည်။ Load balancer က ထို server ကို unhealthy ဟု မှတ်ခဲ့ပြီး remote-command tool က မရောက်နိုင်ခဲ့ပါ။ သို့သော် မည်သည်မျှ crash မဖြစ်ခဲ့ပါ၊ memory သုံးလွန်းသဖြင့် မည်သည့် process မျှ kill မခံရခဲ့ပါ။ Server သည် thrashing ဖြစ်နေခဲ့သည်: swap space မရှိပြီး containers များက စက်၌ ရှိသည်ထက် ပိုသော memory ကို သုံးခွင့်ရှိနေသဖြင့် Linux သည် run ဖို့ လိုအပ်သော ဖိုင်များကို ဖယ်ထုတ်ပြီး ပြန်ဖတ်ရာတွင် အချိန်ကုန်ကာ အလွန်နည်းသော တိုးတက်မှုသာ ရှိခဲ့သည်။ Server တိုင်းတွင် 2 GB swap file ထည့်ခြင်းဖြင့် ပြဿနာ ပြေလည်သွားသည်။ ပိုစိတ်ဝင်စားဖွယ် သင်ခန်းစာမှာ health check များအကြောင်း ဖြစ်သည်။

"ရပ်သွားခြင်း" ဘယ်လို ပုံစံရှိသလဲ

• Load balancer ၏ health check များသည် ထို server တွင် timeout ဖြစ်ခဲ့သည်။
• AWS Systems Manager မှတစ်ဆင့် ပို့သော command များသည် "Pending" တွင် ရပ်ပြီး ဘယ်တော့မှ မ run ခဲ့ပါ။
• Logs တွင် out-of-memory kill မရှိပါ။ Process တစ်ခုမှ မသေခဲ့ပါ။

တစ်ပတ်အလိုက ကျွန်ုပ်တို့သည် production ကို ပိုသေးငယ်သော ARM server များသို့ ရွှေ့ခဲ့ပြီး တစ်ခုစီတွင် RAM 2 GB ရှိသည် (ဘာကြောင့် ARM သို့ ရွှေ့သလဲ)။ ပိုသေးသော staging server သည် deploy အတွင်း container image ကို unpack နေစဉ် အလားတူ ရပ်သွားခဲ့သည်။

Memory error မရှိဘဲ ဘာကြောင့်လဲ

Linux သည် ပြန်ရနိုင်သော memory အမှန်တကယ် ကုန်သွားမှသာ process ကို kill လုပ်သည်။ အဲဒီ အချက်မရောက်မီ page cache မှ memory ကို ပြန်ယူသည်။ Page cache ဆိုသည်မှာ RAM တွင် သိမ်းထားသော ဖိုင်မိတ္တူများဖြစ်ပြီး run နေသော program တိုင်း၏ code ပါဝင်သည်။

ကျွန်ုပ်တို့ server များတွင် containers များ၏ memory limit စုစုပေါင်းသည် အသုံးပြုနိုင်သော ~၁.၈ GB ရှိသော စက်ပေါ်တွင် ~၃.၃ GB ရောက်ခဲ့သည်။ ပုံမှန်အားဖြင့် အားလုံးသည် limit ကို တပြိုင်နက် မသုံးကြပါ။ သုံးသောအခါ kernel သည် cache မှ program code ကို ဖယ်ထုတ်ပြီး ထို code သည် ပြန် run ချိန်တွင် disk မှ ပြန်ဖတ်ရသည်။ ထိုသံသရာ — thrashing — သည် memory အမှန်တကယ် မကုန်ဘဲ စက်ကို လုံးဝ တုံ့ပြန်မှု မရှိအောင် ဖြစ်စေနိုင်သည်။ ထို့ကြောင့် မည်သည်ကိုမျှ kill မခံရပြီး ပြန်မကောင်းလာပါ။

Swap မရှိသော်လည်း kernel သည် ခွဲဝေထားသော်လည်း ရံဖန်ရံခါသာ သုံးသော memory ကို ထားစရာ မရှိသဖြင့် cache မှ ယူရသည်။

ပြင်ဆင်ချက်

Server bootstrap script သည် server တစ်ခု boot သို့မဟုတ် ပြင်တိုင်း 2 GB swap file ကို swappiness 10 ဖြင့် ဖန်တီးသည်။ Swappiness နိမ့်ခြင်းသည် kernel က အလုပ်လုပ်သော memory ကို RAM တွင် ထားရန် ဦးစားပေးသော်လည်း ရံဖန်ရံခါသုံးသော page များကို disk သို့ ရွှေ့နိုင်ပြီး program code ကို cache မှ အတင်းထုတ်ခြင်း မဖြစ်စေပါ။ Production server နှစ်ခုနှင့် staging ကို live တွင် ထည့်ခဲ့ပြီး deploy pipeline က production deploy တိုင်း bootstrap script ကို ပြန်ထုတ်သဖြင့် အစားထိုးထားသော server သည် ၎င်းကို ရရှိမည်။

ပို၍ စိုးရိမ်ရသည့်အချက်: unhealthy server ကျန်ခဲ့သည်

ကျွန်ုပ်တို့၏ server group သည် EC2 health checks ကို သုံးသည် — "စက် run နေသလား?" — load balancer health checks — "request ကို တုံ့ပြန်နေသလား?" — မဟုတ်ပါ။ ထို့ကြောင့် load balancer စွန့်လွှတ်ထားသော server သည် group အနေဖြင့် ကျန်းမာနေဆဲ ဖြစ်သည်။ ဘယ်တော့မှ အစားထိုးခံရမည် မဟုတ်ပါ။ တစ်ဦးတစ်ယောက် သတိမထားမိမချင်းနှင့် အခြားတစ်လုံးကို ပြန်စတင်မချင်း production သည် server တစ်လုံးတည်းဖြင့် တိတ်ဆိတ်စွာ run နေမည်။

Load balancer health checks သို့ ပြောင်းရန်က ရိုးရှင်းသော ပြင်ဆင်ချက်ဟု ထင်ရသော်လည်း ကျွန်ုပ်တို့အတွက် မရိုးရှင်းပါ။ Deploy အတွင်း server များသည် balancer က ရေထုတ်စေရန် health endpoint တွင် error ပြန်ပေးကြောင်း ဆုံးဖြတ်ချက်ဖြင့် ပြုလုပ်သည် (deploy 502 သုည ရအောင် ဘယ်လိုလုပ်သလဲ ကို ကြည့်ပါ)။ ထို signal ဖြင့် server များကို အစားထိုးသော group သည် deploy အလယ်တွင် ထို server များကို အစားထိုးမည်။

ထို့ကြောင့် ယခုအချိန်တွင် deploy checklist တွင် အဆင့်တစ်ခု ထည့်ခဲ့သည်: deploy တိုင်း၏ နောက်တွင် deploy job အောင်မြင်ခြင်းကိုသာမက load balancer ပေါ်ရှိ target တိုင်း၏ health ကို စစ်ပါ။ Server သို့ command များ "Pending" တွင် ရပ်နေလျှင် ၎င်းသည် thrashing ဖြစ်နေသည် — ပြန်ပိတ်ပါ၊ ၎င်းသည် အသုံးပြုမှုမှ ထုတ်ပြီးသားဖြစ်သည်။

ကျွန်ုပ်တို့ ရရှိခဲ့သည့်အရာ

• "Crash မဖြစ်ခြင်း" သည် "ကျန်းမာခြင်း" မဟုတ်ပါ။ Thrashing သည် error မပေးဘဲ စက်ကို တုံ့ပြန်မှု မရှိအောင် နှေးစေသည်။
• Server ငယ်များက swap လိုသည်။ အနည်းငယ်ဖြစ်စေ၊ swappiness နိမ့်ဖြင့် kernel အတွက် အေးသော memory ထားရန် နေရာ ရရှိသည်။
• Memory limit များ စုစုပေါင်းသည် စက်ထက် ကြီးလျှင် ထိုးထားသော ဝင်ငွေ ဖြစ်သည်။ တစ်ခါတစ်ရံ ရှုံးမည်။ သင် ထိုး်ထားသည်ကို သိထားပါ။
• Autoscaling က ယုံကြည်သော health check ကို သိပါ။ "VM ဖွင့်ထားလား?" ဟု မေးသော health check သည် အလုပ်မလုပ်တော့သော server ကို အစားထိုးမည် မဟုတ်ပါ။