ဆောင်းပါး၏ဘာသာပြန်ကို သင်တန်းစသည့်နေ့တွင် ပြင်ဆင်ခဲ့ပါသည်။ .
အခါအားလျော်စွာ၊ ဤနေရာ၌၊ kernel ချိန်ညှိခြင်းဆိုင်ရာ Gluster ၏အကြံပြုချက်များအကြောင်းနှင့်၎င်းအတွက်လိုအပ်မှုရှိမရှိ၊ အခါအားလျော်စွာမေးခွန်းများပေါ်လာသည်။
ဒီလိုမျိုး လိုအပ်ချက်ဆိုတာ ရှားပါတယ်။ အလုပ်တာဝန်အများစုတွင်၊ kernel သည် အလွန်ကောင်းမွန်စွာ လုပ်ဆောင်သည်။ အားနည်းချက်ရှိပေမယ့်။ သမိုင်းကြောင်းအရ၊ Linux kernel သည် စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန် အဓိကနည်းလမ်းအဖြစ် caching ပြုလုပ်ခြင်းအပါအဝင် အခွင့်အလန်းများရရှိပါက memory အများအပြားစားသုံးရန် ဆန္ဒရှိနေပါသည်။
ကိစ္စအများစုတွင်၊ ၎င်းသည် ကောင်းမွန်စွာအလုပ်လုပ်သော်လည်း လေးလံသောဝန်အောက်တွင် ပြဿနာများဖြစ်ပေါ်လာနိုင်သည်။
ကျွန်ုပ်တို့တွင် CAD၊ EDA ကဲ့သို့သော memory အထူးကြပ်မတ်စနစ်များနှင့် အတွေ့အကြုံများစွာရှိပြီး လေးလံသောဝန်အောက်တွင် နှေးကွေးသွားပါသည်။ တစ်ခါတစ်ရံတွင် ကျွန်ုပ်တို့သည် Gluster တွင် ပြဿနာများကြုံခဲ့ရသည်။ မန်မိုရီအသုံးပြုမှုနှင့် ဒစ်ခ်ကြာချိန်ကို ရက်ပေါင်းများစွာ ဂရုတစိုက်ကြည့်ရှုပြီးနောက်၊ ၎င်းတို့၏ ဝန်ပိုမှု၊ ကြီးမားသော အိုင်အိုဝိတ်၊ kernel အမှားအယွင်းများ (kernel oops)၊ အေးခဲမှုများ၊ စသည်တို့ကို ရရှိခဲ့ပါသည်။
ဤဆောင်းပါးသည် အခြေအနေအမျိုးမျိုးတွင် လုပ်ဆောင်ခဲ့သော ချိန်ညှိစမ်းသပ်မှုများစွာ၏ ရလဒ်ဖြစ်သည်။ ဤကန့်သတ်ချက်များကြောင့် အလုံးစုံ တုံ့ပြန်နိုင်စွမ်း တိုးတက်လာသည်သာမက အစုအဖွဲ့သည်လည်း သိသိသာသာ တည်ငြိမ်လာသည်။
မန်မိုရီချိန်ညှိခြင်းနှင့်ပတ်သက်လာလျှင် ပထမဆုံးကြည့်ရှုရမည့်အရာမှာ သင့်အား စိတ်ရှုပ်ထွေးစေမည့် ရွေးချယ်စရာများစွာပါရှိသည့် virtual memory subsystem (VM၊ virtual memory) ဖြစ်သည်။
vm.swappiness
parameter သည် vm.swappiness RAM နှင့်နှိုင်းယှဉ်ပါက kernel သည် swap (swap၊ paging) ကိုမည်မျှအသုံးပြုသည်ကိုဆုံးဖြတ်သည်။ ၎င်းကို အရင်းအမြစ်ကုဒ်တွင် "မြေပုံပြုလုပ်ထားသော မှတ်ဉာဏ်ကို ခိုးယူရန် သဘောထား" ဟုလည်း သတ်မှတ်ထားသည်။ မြင့်မားသော swappiness ဆိုသည်မှာ kernel သည် မြေပုံဆွဲထားသော စာမျက်နှာများကို လဲလှယ်ရန် ပို၍ သဘောထားရှိလိမ့်မည်ဖြစ်သည်။ low swappiness တန်ဖိုးသည် ဆန့်ကျင်ဘက်ဖြစ်သည်ဟု ဆိုလိုသည်- kernel သည် memory မှ page လျော့နည်းသွားမည်ဖြစ်သည်။ တစ်နည်းဆိုရသော် တန်ဖိုးမြင့်သည်။ vm.swappinessစနစ်က swap ကို ပိုသုံးလာလိမ့်မယ်။
ဒေတာအများအပြားကို RAM ထဲသို့ တင်ပြီး ဖြုတ်လိုက်သောကြောင့် ကြီးမားသော လဲလှယ်အသုံးပြုမှုသည် မလိုလားအပ်ပေ။ လူများစွာသည် swapiness တန်ဖိုးသည် ကြီးမားသင့်သည်ဟု စောဒကတက်သော်လည်း ကျွန်ုပ်၏ အတွေ့အကြုံအရ ၎င်းကို "0" ဟု သတ်မှတ်ခြင်းသည် ပိုမိုကောင်းမွန်သော စွမ်းဆောင်ရည်ကို ရရှိစေပါသည်။
ဤနေရာတွင် ဆက်လက်ဖတ်ရှုနိုင်ပါသည်-
သို့သော်၊ တစ်ဖန်၊ ဤဆက်တင်များကို ဂရုတစိုက်နှင့် အသုံးချသင့်ပြီး သီးခြားအက်ပလီကေးရှင်းတစ်ခုကို စမ်းသပ်ပြီးနောက်မှသာ အသုံးပြုသင့်သည်။ အလွန်တင်ထားသော streaming အပလီကေးရှင်းများအတွက်၊ ဤကန့်သတ်ချက်ကို "0" ဟု သတ်မှတ်သင့်သည်။ "0" သို့ ပြောင်းသောအခါ စနစ်၏ တုံ့ပြန်မှု ပိုမိုကောင်းမွန်လာသည်။
vm.vfs_cache_pressure
ဤဆက်တင်သည် ကက်ရှ်လမ်းညွှန်နှင့် အိုင်းနိုဒီးယားအရာများ (အံသွားနှင့် အင်ဒရို) အတွက် kernel မှစားသုံးသော မမ်မိုရီကို ထိန်းချုပ်သည်။
မူရင်းတန်ဖိုး 100 ဖြင့်၊ kernel သည် pagecache နှင့် swapcache အတွက် "တရားမျှတသော" အခြေခံဖြင့် dentry နှင့် inode cache ကို ဖယ်ရှားရန် ကြိုးစားမည်ဖြစ်သည်။ vfs_cache_pressure ကျဆင်းခြင်းသည် kernel အား dentry နှင့် inode cache ကို ထားရှိစေသည်။ တန်ဖိုးသည် "0" ဖြစ်သောအခါ kernel သည် memory pressure ကြောင့် dentry နှင့် inode cache ကို ဘယ်တော့မှ ရှင်းထုတ်မည်မဟုတ်ပါ၊ ၎င်းသည် အလွယ်တကူ memory out-of-memory error ကို ဖြစ်ပေါ်စေနိုင်သည်။ 100 အထက် vfs_cache_pressure တိုးလာခြင်းသည် kernel သည် သွားနှင့်ခံတွင်း နှင့် inode flushing ကို ဦးစားပေးလုပ်စေသည်။
GlusterFS ကိုအသုံးပြုသောအခါ၊ ဒေတာအများအပြားနှင့် ဖိုင်ငယ်များစွာရှိသော သုံးစွဲသူအများအပြားသည် inode/dentry caching ကြောင့် ဆာဗာပေါ်တွင် RAM ပမာဏကို အလွယ်တကူ အသုံးပြုနိုင်ပြီး၊ ၎င်းသည် kernel သည် စနစ်တစ်ခုပေါ်တွင် ဒေတာဖွဲ့စည်းပုံများကို လုပ်ဆောင်ရသည့်အတွက် စွမ်းဆောင်ရည်ကျဆင်းသွားနိုင်သည်။ Memory 40 GB ပါရှိပါတယ်။ 100 အထက်တွင် ဤတန်ဖိုးကို သတ်မှတ်ခြင်းသည် အသုံးပြုသူအများအပြားကို ပိုမိုမျှတသော ကက်ရှ်ချခြင်းနှင့် kernel တုံ့ပြန်မှု ပိုမိုကောင်းမွန်လာစေရန် ကူညီပေးပါသည်။
vm.dirty_background_ratio နှင့် vm.dirty_ratio
ပထမ သတ်မှတ်ချက် (vm.dirty_background_ratio) ညစ်ပတ်သောစာမျက်နှာများပါရှိသော မမ်မိုရီရာခိုင်နှုန်းကို သတ်မှတ်ပေးသည် ဤရာခိုင်နှုန်းကို မရောက်မချင်း၊ စာမျက်နှာများကို ဒစ်ခ်သို့ လွှင့်မပစ်ရပါ။ ပြန်လည်သတ်မှတ်ခြင်းစတင်သောအခါ၊ ၎င်းသည် လုပ်ဆောင်နေသည့်လုပ်ငန်းစဉ်များကို အနှောင့်အယှက်မဖြစ်စေဘဲ နောက်ခံတွင်အလုပ်လုပ်သည်။
ဒုတိယ သတ်မှတ်ချက် (vm.dirty_ratio) အတင်းဖလက်ရ်ှမစတင်မီ ညစ်ပတ်သောစာမျက်နှာများမှ သိမ်းပိုက်နိုင်သည့် ရာခိုင်နှုန်းကို သတ်မှတ်သည်။ ဤအဆင့်သို့ရောက်သည်နှင့်၊ လုပ်ငန်းစဉ်အားလုံးသည် တစ်ပြိုင်နက်တည်း (ပိတ်ဆို့ထားသည်) ဖြစ်လာပြီး ၎င်းတို့တောင်းဆိုထားသော I/O အမှန်တကယ် ပြီးမြောက်ပြီး ဒေတာဒစ်ပေါ်တွင် ရှိနေသည်အထိ ဆက်လက်လုပ်ဆောင်ရန် ခွင့်မပြုပါ။ လေးလံသော I/O ဖြင့် ၎င်းသည် ဒေတာ သိမ်းဆည်းခြင်း မရှိသောကြောင့် I/O လုပ်ဆောင်သည့် လုပ်ငန်းစဉ်အားလုံးကို ပိတ်ဆို့ထားသောကြောင့် I/O ကို စောင့်မျှော်နေပါသည်။ ၎င်းသည် ချိတ်ဆွဲထားသော လုပ်ငန်းစဉ်အများအပြား၊ ဝန်မြင့်မားမှု၊ စနစ်မတည်ငြိမ်မှုနှင့် စွမ်းဆောင်ရည် ညံ့ဖျင်းမှုကို ဖြစ်စေသည်။
ဤဆက်တင်များကို လျှော့ချခြင်းဖြင့် ဒေတာကို ဒစ်ခ်သို့ မကြာခဏ လွှင့်ပစ်ရမည်ဖြစ်ပြီး RAM တွင် မသိမ်းဆည်းနိုင်ပါ။ ၎င်းသည် 45-90 GB စာမျက်နှာ ကက်ရှ်များကို ဒစ်ခ်သို့ ဖယ်ရှားခြင်းဖြင့် အဆင်ပြေသော မန်မိုရီ-လေးလံသော စနစ်များကို ကူညီပေးနိုင်ပြီး၊ ရှေ့ဆုံး အက်ပ်လီကေးရှင်းများအတွက် ကြီးမားသော latency ကို ဖြစ်ပေါ်စေကာ အလုံးစုံ တုံ့ပြန်နိုင်စွမ်းနှင့် အပြန်အလှန်တုံ့ပြန်မှုကို လျှော့ချနိုင်သည်။
"1" > /proc/sys/vm/pagecache
စာမျက်နှာ cache သည် ဖိုင်များနှင့် လည်ပတ်နိုင်သော ပရိုဂရမ်များ၏ အချက်အလက်များကို သိမ်းဆည်းထားသည့် ကက်ရှ်တစ်ခုဖြစ်ပြီး၊ ဆိုလိုသည်မှာ ၎င်းတို့သည် ဖိုင်များ သို့မဟုတ် ပိတ်ဆို့သည့် စက်ပစ္စည်းများ၏ အမှန်တကယ်ပါဝင်သည့် စာမျက်နှာများဖြစ်သည်။ ဒီကက်ရှ်ကို ဒစ်ခ်ဖတ်သည့်အရေအတွက်ကို လျှော့ချရန်အတွက် အသုံးပြုသည်။ "1" ၏တန်ဖိုးဆိုသည်မှာ ကက်ရှ်အတွက် RAM ၏ 1% ကိုအသုံးပြုပြီး RAM မှထက် disk မှဖတ်မှုများပိုမိုရရှိမည်ဖြစ်သည်။ ဤဆက်တင်ကို ပြောင်းလဲရန် မလိုအပ်သော်လည်း စာမျက်နှာ ကက်ရှ်ကို ထိန်းချုပ်ရန် အကြောက်လွန်နေပါက ၎င်းကို အသုံးပြုနိုင်ပါသည်။
"deadline" > /sys/block/sdc/queue/scheduler
I/O အချိန်ဇယားသည် တန်းစီစာများကို ဖတ်ရှုခြင်းနှင့် ရေးသားခြင်းများကို ကိုင်တွယ်သည့် Linux kernel အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ သီအိုရီအရ၊ စမတ် RAID controller အတွက် "noop" ကို သုံးခြင်းသည် ပိုကောင်းသည်၊ အကြောင်းမှာ Linux သည် disk ၏ ရုပ်ပိုင်းဆိုင်ရာ ဂျီသြမေတြီအကြောင်း ဘာမှ မသိသောကြောင့်၊ disk geometry ကို ကောင်းစွာသိသော controller ကို ခိုင်းစေခြင်းဖြင့် တောင်းဆိုမှုကို မြန်မြန်ဆန်ဆန် လုပ်ဆောင်နိုင်စေရန် ပိုထိရောက်ပါသည်။ ဖြစ်နိုင်သည်။ ဒါပေမယ့် "deadline" က စွမ်းဆောင်ရည်ကို တိုးတက်ကောင်းမွန်စေပုံပါပဲ။ Linux kernel အရင်းအမြစ်ကုဒ်စာရွက်စာတမ်းများတွင် အချိန်ဇယားဆွဲသူများအကြောင်း ပိုမိုဖတ်ရှုနိုင်သည်- linux/Documentation/block/*osched.txt. ရောနှောလုပ်ဆောင်မှုများတွင် (အများအပြားရေးထားသည်) တွင်လည်း ဖတ်ရှုနိုင်မှု တိုးလာသည်ကို ကျွန်ုပ်တွေ့မြင်ခဲ့ရပါသည်။
"256" > /sys/block/sdc/queue/nr_requests
အစီအစဉ်ဆွဲသူထံ မပေးပို့မီ ကြားခံရှိ I/O တောင်းဆိုမှုအရေအတွက်။ ထိန်းချုပ်သူအချို့၏ အတွင်းပိုင်းတန်းစီခြင်းအရွယ်အစား (queue_depth) သည် I/O အစီအစဉ်ဆွဲသူ၏ nr_requests များထက် ပိုကြီးသောကြောင့် I/O အစီအစဉ်ဆွဲသူသည် တောင်းဆိုချက်များကို ဦးစားပေးပြီး ပေါင်းစည်းရန် အခွင့်အရေးနည်းပါးပါသည်။ နောက်ဆုံးရက်နှင့် CFQ အချိန်ဇယားများအတွက်၊ nr_requests သည် controller ၏အတွင်းပိုင်းတန်းစီထက် 2 ဆ ပိုကောင်းပါသည်။ တောင်းဆိုချက်များကို ပေါင်းစည်းခြင်းနှင့် ပြန်လည်စီစစ်ခြင်းများသည် လေးလံသောဝန်ထုပ်ဝန်ပိုးအောက်တွင် အချိန်ဇယားဆွဲအား ပိုမိုတုံ့ပြန်နိုင်စေရန် ကူညီပေးသည်။
ပဲ့တင်သံ "16" > /proc/sys/vm/page-cluster
စာမျက်နှာ-အစုအဝေး ကန့်သတ်ဘောင်သည် တစ်ကြိမ်တည်းတွင် လဲလှယ်ရန် ရေးသားထားသော စာမျက်နှာအရေအတွက်ကို ထိန်းချုပ်သည်။ အထက်ဖော်ပြပါ ဥပမာတွင်၊ 16 KB ၏ RAID အစင်းအရွယ်အစားအရ တန်ဖိုးကို "64" ဟု သတ်မှတ်သည်။ swappiness = 0 နှင့် အဓိပ္ပါယ်မရှိသော်လည်း swappiness ကို 10 သို့မဟုတ် 20 ဟု သတ်မှတ်ပါက RAID အစင်းအရွယ်အစား 64K ဖြစ်သောအခါ ဤတန်ဖိုးကို အသုံးပြုခြင်းဖြင့် သင့်အား ကူညီပေးပါမည်။
blockdev --setra 4096 /dev/<devအမည်> (-sdb၊ hdc သို့မဟုတ် dev_mapper)
RAID ထိန်းချုပ်ကိရိယာများစွာအတွက် ပုံသေပိတ်ဆို့သည့်ကိရိယာဆက်တင်များသည် မကြာခဏဆိုသလို ဆိုးရွားသောစွမ်းဆောင်ရည်ကိုဖြစ်ပေါ်စေသည်။ အထက်ဖော်ပြပါ ရွေးချယ်မှုကို ပေါင်းထည့်ခြင်းသည် 4096 * 512-byte ကဏ္ဍများအတွက် ဖတ်ရှုရန် ရှေ့သို့ သတ်မှတ်ပေးသည်။ အနည်းဆုံးတော့၊ တိုက်ရိုက်ထုတ်လွှင့်ခြင်းဆိုင်ရာ လုပ်ဆောင်ချက်များအတွက်၊ I/O ပြင်ဆင်ရန်အတွက် kernel မှအသုံးပြုသည့်ကာလအတွင်းတွင် အွန်လိုင်းချစ်ပ်ဒစ်ကက်ရှ်ကို ဖတ်ရှုခြင်းနှင့်အတူ ဖြည့်သွင်းခြင်းဖြင့် အရှိန်တိုးစေသည်။ ကက်ရှ်တွင် နောက်ဖတ်မည့်စာတွင် တောင်းဆိုမည့် ဒေတာများ ပါဝင်နိုင်သည်။ ကြိုတင်ထုတ်ယူမှု အလွန်အကျွံသည် အသုံးဝင်နိုင်ဖွယ်ရှိသော ဒစ်ခ်အချိန်ကို အသုံးပြုခြင်း သို့မဟုတ် ကက်ရှ်ပြင်ပတွင် ဒေတာများတင်ပါက ကြီးမားသောဖိုင်များအတွက် ကျပန်း I/O ကို သတ်ပစ်နိုင်သည်။
အောက်တွင် ဖိုင်စနစ်အဆင့်ရှိ နောက်ထပ် အကြံပြုချက်အချို့ဖြစ်သည်။ ဒါပေမယ့် သူတို့ မစမ်းသပ်ရသေးဘူး။ သင့်ဖိုင်စနစ်သည် အစင်းကြောင်းအရွယ်အစားနှင့် ခင်းကျင်းရှိ disk အရေအတွက်ကို သိရှိကြောင်း သေချာပါစေ။ ဥပမာအားဖြင့်၊ ၎င်းသည် ဒစ်ခြောက်ခု၏ 5K အစင်းတိုက်ခိုက်မှု 64 အခင်းအကျင်းတစ်ခုဖြစ်သည် (တကယ်တော့ ငါးခု၊ တစ်ခုသောဒစ်ကို ညီမျှမှုအတွက်အသုံးပြုသောကြောင့်)။ ဤအကြံပြုချက်များကို RAID ကျွမ်းကျင်သူများမှ အမျိုးမျိုးသော ဘလော့ဂ်များ/ဆောင်းပါးများမှ သီအိုရီဆိုင်ရာ ယူဆချက်များအပေါ် အခြေခံ၍ စုစည်းထားပါသည်။
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))ကြီးမားသောဖိုင်များအတွက်၊ အထက်ဖော်ပြပါ အစင်းအရွယ်အစားများကို တိုးမြှင့်စဉ်းစားပါ။
သတိပေးချက်! အထက်တွင်ဖော်ပြထားသည့်အရာအားလုံးသည် အချို့သောအပလီကေးရှင်းအမျိုးအစားများအတွက် အလွန်ပုဂ္ဂလဒိဋ္ဌိဖြစ်သည်။ ဆက်စပ်အပလီကေးရှင်းများကို အသုံးပြုသူကြိုတင်စမ်းသပ်ခြင်းမရှိဘဲ တိုးတက်မှုတစ်စုံတစ်ရာကို ဤဆောင်းပါးတွင် အာမမခံနိုင်ပါ။ စနစ်၏ အလုံးစုံတုံ့ပြန်နိုင်စွမ်းကို မြှင့်တင်ရန် လိုအပ်ပါက သို့မဟုတ် လက်ရှိပြဿနာများကို ဖြေရှင်းနိုင်မှသာ ၎င်းကို အသုံးပြုသင့်သည်။
အပိုဆောင်းပစ္စည်းများ:
ပိုပြီးဖတ်ပါ
source: www.habr.com