Roman Gushchin () Facebook မှ Linux kernel developer များ၏ mailing list တွင် memory allocation controller အသစ်ကို အကောင်အထည်ဖော်ခြင်းဖြင့် patch အစုံ၊ (slab memory controller)။ ထိန်းချုပ်သူအသစ်သည် cgroup တစ်ခုစီအတွက် သီးခြား slab ကက်ရှ်များကို ခွဲဝေပေးမည့်အစား slab စာမျက်နှာများကို မတူညီသော cgroups တွင် မျှဝေနိုင်စေသည့် memory page အဆင့်မှ kernel object အဆင့်သို့ slab အကောင့်ကို ရွှေ့ခြင်းအတွက် မှတ်သားဖွယ်ဖြစ်ပါသည်။
အဆိုပြုထားသောချဉ်းကပ်မှုသည် slab ကိုအသုံးပြုခြင်း၏ထိရောက်မှုကိုတိုးမြှင့်ရန်၊ slab အတွက်အသုံးပြုသည့်မှတ်ဉာဏ်အရွယ်အစားကို 30-45% လျှော့ချရန်နှင့် kernel ၏အလုံးစုံမှတ်ဉာဏ်သုံးစွဲမှုကို သိသိသာသာလျှော့ချနိုင်စေသည်။ မရွှေ့မပြောင်းနိုင်သော slabs အရေအတွက်ကို လျှော့ချခြင်းဖြင့် memory fragmentation ကို လျှော့ချရာတွင် အပြုသဘောဆောင်သော အကျိုးသက်ရောက်မှုများ ရှိပါသည်။ မမ်မိုရီထိန်းချုပ်ကိရိယာအသစ်သည် slabs များအတွက် စာရင်းအင်းကုဒ်ကို သိသိသာသာရိုးရှင်းစေပြီး cgroup တစ်ခုစီအတွက် slab ကက်ရှ်များကို ဒိုင်းနမစ်ဖန်တီးခြင်းနှင့် ဖျက်ခြင်းအတွက် ရှုပ်ထွေးသော algorithms များကို အသုံးပြုရန်မလိုအပ်ပါ။ အကောင်အထည်ဖော်မှုအသစ်ရှိ မမ်မိုရီ cgroups အားလုံးသည် slab ကက်ရှ်များ၏ ဘုံအစုအဝေးကို အသုံးပြုကြပြီး၊ slab ကက်ရှ်များ၏ သက်တမ်းသည် cgroup မှတဆင့် ထည့်သွင်းထားသူများ၏ သက်တမ်းနှင့် ဆက်စပ်မှုမရှိတော့ပါ။ မှတ်ဉာဏ်အသုံးပြုမှုအပေါ်။
slab controller အသစ်တွင် ပိုမိုတိကျသော အရင်းအမြစ်စာရင်းအင်းကို အကောင်အထည်ဖော်လေသည် သီအိုရီအရ CPU ကို ပိုတင်သင့်သော်လည်း လက်တွေ့တွင် ကွာခြားချက်များသည် အရေးမပါလှပါ။ အထူးသဖြင့် slab controller အသစ်ကို ထုတ်လုပ်မှု အမျိုးအစားအမျိုးမျိုးကို ကိုင်တွယ်သည့် Facebook ဆာဗာများတွင် လအတော်ကြာ အသုံးပြုခဲ့ပြီး သိသာထင်ရှားသော ဆုတ်ယုတ်မှုများကို ဖော်ထုတ်နိုင်ခြင်း မရှိသေးပါ။ တစ်ချိန်တည်းမှာပင်၊ မမ်မိုရီသုံးစွဲမှုမှာ သိသာထင်ရှားစွာ လျော့ကျသွားသည် - အချို့သောအိမ်ရှင်များတွင် မမ်မိုရီ 1GB အထိ သိမ်းဆည်းနိုင်သော်လည်း ဤညွှန်ကိန်းသည် ဝန်၏သဘောသဘာဝ၊ RAM စုစုပေါင်းအရွယ်အစား၊ CPU အရေအတွက်ပေါ်တွင် အလွန်မူတည်ပါသည်။ နှင့် memory ဖြင့်အလုပ်လုပ်ခြင်း၏အင်္ဂါရပ်များ။ ယခင်စမ်းသပ်မှုများ ဝဘ်၏ ရှေ့ဆုံးတွင် 650-700 MB (42% slab memory)၊ DBMS cache ပါရှိသည့် ဆာဗာတွင် 750-800 MB (35%) နှင့် DNS server တွင် 700 MB (36%)။
source: opennet.ru