အမြဲတမ်းဒေတာသိုလှောင်မှုနှင့်ဖိုင် API များ Linux

ကျွန်ုပ်သည် cloud စနစ်များတွင် ဒေတာသိုလှောင်မှု တည်ငြိမ်မှုကို သုတေသနပြုကာ အခြေခံအရာများကို နားလည်ကြောင်း သေချာစေရန် မိမိကိုယ်ကို စမ်းသပ်ရန် ဆုံးဖြတ်ခဲ့သည်။ ငါ NVMe spec ကိုဖတ်ခြင်းဖြင့်စတင်ခဲ့သည်။ ဒေတာဆက်လက်တည်မြဲမှုနှင့်ပတ်သက်သော အာမခံချက်များကို နားလည်ရန်အတွက် (ဆိုလိုသည်မှာ စနစ်ပျက်ကွက်ပြီးနောက် ဒေတာရရှိနိုင်ကြောင်း အာမခံချက်) သည် ကျွန်ုပ်တို့အား NMVe disk များကို ပေးပါ။ ကျွန်ုပ်သည် အောက်ပါ အဓိက ကောက်ချက်ချခဲ့သည်- ဒေတာရေးရန် အမိန့်ပေးသည့်အချိန်မှ ပျက်စီးသွားသော ဒေတာကို သိမ်းဆည်းသည့် ကြားခံသို့ စာရေးပြီးသည့်တိုင်အောင် ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။ သို့သော်၊ ပရိုဂရမ်အများစုတွင်၊ စနစ်ခေါ်ဆိုမှုများသည် အချက်အလက်ရေးရန် အလွန်လုံခြုံစွာ အသုံးပြုပါသည်။

ဤဆောင်းပါးတွင်၊ ဖိုင် API များမှ ပံ့ပိုးပေးသော ရေရှည်ဒေတာသိုလှောင်မှု ယန္တရားများကို ကျွန်ုပ် လေ့လာပါမည်။ Linuxဒီမှာ အရာအားလုံးက ရိုးရှင်းသင့်တယ်လို့ ထင်ရတယ်- ပရိုဂရမ်က command ကို ခေါ်ပါတယ် write()၊ ဤအမိန့်တော်၏လုပ်ဆောင်ချက်ပြီးမြောက်ပြီးနောက်၊ ဒေတာကို ဒစ်ခ်ပေါ်တွင် လုံခြုံစွာသိမ်းဆည်းထားမည်ဖြစ်သည်။ ဒါပေမယ့် write() အပလီကေးရှင်းဒေတာကို RAM တွင်ရှိသော kernel cache သို့သာကူးယူသည်။ ဒေတာကို ဒစ်ခ်သို့ ရေးရန် စနစ်အား တွန်းအားပေးရန်အတွက်၊ အချို့သော နောက်ထပ် ယန္တရားများကို အသုံးပြုရပါမည်။

ယေဘူယျအားဖြင့်၊ ဤအကြောင်းအရာသည် ကျွန်ုပ်စိတ်ဝင်စားသော ခေါင်းစဉ်တစ်ခုတွင် ကျွန်ုပ်သင်ယူခဲ့ရာများနှင့် သက်ဆိုင်သော မှတ်စုအစုစုဖြစ်သည်။ အရေးကြီးဆုံးအကြောင်း အတိုချုပ်ပြောရင် ရေရှည်တည်တံ့တဲ့ data storage ကို စုစည်းဖို့အတွက် command ကိုသုံးဖို့ လိုအပ်ပါတယ် fdatasync() သို့မဟုတ် အလံဖြင့် ဖိုင်များကိုဖွင့်ပါ။ O_DSYNC. ကုဒ်မှဒစ်ဆီသို့ ဒေတာများဖြစ်ပျက်ပုံအကြောင်း ပိုမိုလေ့လာရန် စိတ်ဝင်စားပါက၊ ကြည့်ရှုပါ။ ဤ ဆောင်းပါး။

write() function ကိုအသုံးပြုခြင်း၏အင်္ဂါရပ်များ

စနစ်ခေါ်ဆိုမှု write() စံသတ်မှတ်ထားသည်။ IEEE POSIX ဖိုင်ဖော်ပြချက်ပေးသူထံ ဒေတာရေးရန် ကြိုးပမ်းမှုအဖြစ်။ အလုပ်ပြီးမြောက်အောင်မြင်ပါစေ။ write() data read operations များသည် ယခင်က ရေးသားခဲ့သည့် bytes အတိအကျကို ပြန်ပေးရပါမည်။ဒီမှာ POSIX စံနှုန်း၏ သက်ဆိုင်သည့်အပိုင်း)။ ဒါဟာဖြစ်ပါတယ်ပုံမှန်ဖိုင်လုပ်ဆောင်မှုများနှင့် thread များ၏အပြန်အလှန်တုံ့ပြန်မှုဆိုင်ရာအပိုင်းတွင်၊ thread နှစ်ခုတစ်ခုစီသည် ဤလုပ်ဆောင်ချက်များကိုခေါ်ဆိုပါက၊ ခေါ်ဆိုမှုတစ်ခုစီသည် အခြားခေါ်ဆိုမှု၏လုပ်ဆောင်မှုဆီသို့ဦးတည်သည့်အကျိုးဆက်များအားလုံးကိုမြင်ရမည်ဟုဖော်ပြထားသည့်မှတ်ချက်တစ်ခုပါရှိသည်။ ဘာအကျိုးဆက်မှ မတွေ့ဘူး။ ၎င်းသည် ဖိုင် I/O လုပ်ဆောင်ချက်များအားလုံးတွင် အလုပ်လုပ်နေသော အရင်းအမြစ်အပေါ် လော့ခ်ချရမည်ဟု ကောက်ချက်ချစေသည်။

စစ်ဆင်ရေးကို ဆိုလိုသလား write() အနုမြူဗုံးလား နည်းပညာပိုင်းအရတော့ ဟုတ်ပါတယ်။ ဒေတာဖတ်ခြင်း လုပ်ဆောင်ချက်များသည် ရေးထားသည့်အရာများအားလုံးကို သို့မဟုတ် တစ်ခုမျှ ပြန်ပေးရပါမည်။ write(). ဒါပေမယ့် စစ်ဆင်ရေး write()စံချိန်စံညွှန်းနဲ့အညီ ရေးခိုင်းသမျှကို ချရေးပြီး အဆုံးထိရေးစရာမလိုပါဘူး။ အချက်အလက်၏ တစ်စိတ်တစ်ပိုင်းသာ ရေးသားခွင့်ရှိသည်။ ဥပမာအားဖြင့်၊ တူညီသောဖိုင်ဖော်ပြချက်ပေးသူမှဖော်ပြသောဖိုင်တစ်ခုသို့ 1024 bytes ပေါင်းထည့်သည့်တစ်ခုစီတွင် တိုက်ရိုက်ထုတ်လွှင့်မှုနှစ်ခုရှိသည်။ စံ၏ရှုထောင့်မှကြည့်လျှင် စာရေးခြင်းလုပ်ငန်းတစ်ခုစီသည် ဖိုင်တွင် တစ်ဘိုက်သာ ပေါင်းထည့်နိုင်သည့်အခါ ရလဒ်ကို လက်ခံနိုင်မည်ဖြစ်သည်။ ဤလုပ်ဆောင်ချက်များသည် အနုမြူဗုံးအဖြစ် ဆက်လက်တည်ရှိနေမည်ဖြစ်ပြီး၊ သို့သော် ၎င်းတို့ပြီးဆုံးပြီးနောက်၊ ဖိုင်သို့ ရေးထားသော အချက်အလက်များသည် ရှုပ်ထွေးသွားမည်ဖြစ်သည်။ ဒီမှာ Stack Overflow တွင် ဤအကြောင်းအရာနှင့်ပတ်သက်၍ အလွန်စိတ်ဝင်စားဖွယ်ကောင်းသော ဆွေးနွေးမှုဖြစ်သည်။

fsync() နှင့် fdatasync() လုပ်ဆောင်ချက်များ

ဒေတာကို disk သို့ flush ရန်အလွယ်ကူဆုံးနည်းလမ်းမှာ function ကိုခေါ်ဆိုခြင်းဖြစ်သည်။ fsync(). ဤလုပ်ဆောင်ချက်သည် စက်လည်ပတ်မှုစနစ်ကို ကက်ရှ်မှ ဒစ်ခ်သို့ ပြုပြင်ထားသော ဘလောက်များအားလုံးကို ရွှေ့ခိုင်းသည်။ ၎င်းတွင် ဖိုင်၏ မက်တာဒေတာအားလုံး (ဝင်ရောက်ချိန်၊ ဖိုင်မွမ်းမံချိန်၊ စသည်ဖြင့်) ပါဝင်သည်။ ဤမက်တာဒေတာသည် ရှားရှားပါးပါး လိုအပ်သည်ဟု ကျွန်ုပ်ယုံကြည်သည်၊ ထို့ကြောင့် ၎င်းသည် သင့်အတွက် အရေးမကြီးကြောင်း သိပါက လုပ်ဆောင်ချက်ကို သင်အသုံးပြုနိုင်ပါသည်။ fdatasync()။ အဆိုပါ ကူညီကြပါ အပေါ် fdatasync() ဤလုပ်ဆောင်ချက်၏ လုပ်ဆောင်မှုအတွင်း၊ ထိုကဲ့သို့သော မက်တာဒေတာပမာဏကို ဒစ်ခ်တွင် သိမ်းဆည်းထားကြောင်း၊ ၎င်းသည် "အောက်ပါဒေတာဖတ်ရှုခြင်းဆိုင်ရာ လုပ်ဆောင်ချက်များကို မှန်ကန်သောလုပ်ဆောင်မှုအတွက် လိုအပ်သည်" ဟု ဖော်ပြထားသည်။ ဤသည်မှာ အပလီကေးရှင်းအများစု အလေးထားသည့်အရာဖြစ်သည်။

ဤနေရာတွင် ဖြစ်ပေါ်လာနိုင်သည့် ပြဿနာတစ်ခုမှာ ဖြစ်နိုင်ခြေရှိသော ချို့ယွင်းမှုတစ်ခုပြီးနောက် ဖိုင်ကို ရှာတွေ့နိုင်သည်ဟု ဤယန္တရားများက အာမခံချက်မပေးခြင်းကြောင့်ဖြစ်သည်။ အထူးသဖြင့်၊ ဖိုင်အသစ်တစ်ခုဖန်တီးသောအခါ၊ ဖုန်းခေါ်ဆိုသင့်သည်။ fsync() ၎င်းတွင်ပါရှိသောလမ်းညွှန်အတွက်။ မဟုတ်ပါက ပျက်ကျပြီးနောက်၊ ဤဖိုင်မရှိဟု ပေါ်လာနိုင်သည်။ ၎င်းအတွက်အကြောင်းပြချက်မှာ UNIX အောက်တွင် hard links များကိုအသုံးပြုခြင်းကြောင့်၊ directory အများအပြားတွင်ဖိုင်တစ်ခုတည်ရှိနိုင်သောကြောင့်ဖြစ်သည်။ ထို့ကြောင့် ခေါ်သောအခါ၊ fsync() ဖိုင်တစ်ခုသည် မည်သည့် directory data ကိုလည်း disk သို့ ရှင်းထုတ်ရမည်ကို သိရန် နည်းလမ်းမရှိပါ။ဒီမှာ ဤအကြောင်းပိုမိုဖတ်ရှုနိုင်ပါသည်။) ext4 ဖိုင်စနစ်သည် လုပ်ဆောင်နိုင်စွမ်းရှိပုံရသည်။ အလိုအလျှောက် အသုံးပြုသည် fsync() သက်ဆိုင်ရာဖိုင်များပါရှိသော လမ်းညွှန်များသို့၊ သို့သော် ၎င်းသည် အခြားဖိုင်စနစ်များနှင့် အဆင်မပြေနိုင်ပါ။

ဤယန္တရားကို မတူညီသော ဖိုင်စနစ်များတွင် ကွဲပြားစွာ အကောင်အထည်ဖော်နိုင်သည်။ ငါသုံးခဲ့တယ် blktrace ext4 နှင့် XFS ဖိုင်စနစ်များတွင် မည်သည့် disk လုပ်ဆောင်ချက်များကို အသုံးပြုကြသည်ကို လေ့လာရန်။ နှစ်ခုစလုံးသည် ဖိုင်များ၏ အကြောင်းအရာများနှင့် ဖိုင်စနစ်ဂျာနယ်နှစ်ခုစလုံးအတွက် ပုံမှန်အတိုင်းရေးရန် command များကို FUA (Force Unit Access၊ disk သို့ တိုက်ရိုက်စာရေးခြင်း၊ cache ကိုကျော်ဖြတ်ခြင်း) ကို ဂျာနယ်သို့ ရေးသားခြင်းဖြင့် ကက်ရှ်ကိုဖယ်ရှားပြီး ထွက်ပေါက်ကို ထုတ်ပေးသည်။ အရောင်းအဝယ်၏အချက်ကို အတည်ပြုရန်အတွက် ၎င်းတို့သည် ယင်းကို လုပ်ဆောင်နိုင်ဖွယ်ရှိသည်။ FUA ကိုမပံ့ပိုးသော drive များတွင်၎င်းသည် cache flush နှစ်ခုဖြစ်ပေါ်စေသည်။ ကျွန်ုပ်၏စမ်းသပ်မှုများက ယင်းကိုပြသခဲ့သည်။ fdatasync() နည်းနည်းမြန်တယ်။ fsync(). ရှိမှာပေါ့။ blktrace ညွှန်ပြသည်။ fdatasync() များသောအားဖြင့် disk တွင် data နည်းပါးသည် (ext4 တွင် fsync() 20 KiB နဲ့ရေးတယ်။ fdatasync() - 16 KiB)။ ထို့အပြင် XFS သည် ext4 ထက်အနည်းငယ်ပိုမြန်သည်ကိုကျွန်တော်သိခဲ့သည်။ လေးလေး blktrace အဲဒါကို ရှာတွေ့နိုင်ခဲ့တယ်။ fdatasync() ဒေတာလျှော့နည်းသောဒစ် (XFS တွင် 4 KiB)။

fsync() ကို အသုံးပြုသောအခါ မရေရာသော အခြေအနေများ

မရေရာသော အခြေအနေသုံးရပ်ကို တွေးကြည့်နိုင်သည်။ fsync()ငါလက်တွေ့တွေ့ပြီးပြီ။

ထိုကဲ့သို့သော အဖြစ်အပျက်သည် ၂၀၀၈ ခုနှစ်တွင် ပထမဆုံး ဖြစ်ပွားခဲ့သည်။ ထိုအချိန်တွင်၊ ဖိုင်အမြောက်အမြားကို disk သို့စာရေးနေပါက Firefox 2008 interface သည် "frozen" ဖြစ်သည်။ ပြဿနာမှာ အင်တာဖေ့စ်ကို အကောင်အထည်ဖော်ခြင်းသည် ၎င်း၏အခြေအနေနှင့်ပတ်သက်သည့် အချက်အလက်များကို သိမ်းဆည်းရန် SQLite ဒေတာဘေ့စ်ကို အသုံးပြုခဲ့ခြင်း ဖြစ်သည်။ အင်တာဖေ့စ်တွင် ဖြစ်ပေါ်ခဲ့သော ပြောင်းလဲမှုတစ်ခုစီပြီးနောက်၊ လုပ်ဆောင်ချက်ကို ခေါ်သည်။ fsync()တည်ငြိမ်သောဒေတာသိမ်းဆည်းခြင်းအတွက် ကောင်းမွန်သောအာမခံချက်ပေးသော၊ ထို့နောက်အသုံးပြုသော ext3 ဖိုင်စနစ်တွင်၊ လုပ်ဆောင်ချက် fsync() စနစ်အတွင်းရှိ "ညစ်ပတ်သော" စာမျက်နှာများအားလုံးကို ဖယ်ထုတ်ပြီး သက်ဆိုင်ရာဖိုင်နှင့် သက်ဆိုင်သော ဖိုင်များသာမကဘဲ၊ ဆိုလိုသည်မှာ Firefox တွင် ခလုတ်တစ်ခုကို နှိပ်လိုက်ခြင်းသည် စက္ကန့်များစွာ ကြာနိုင်သည့် သံလိုက်ဒစ်တစ်ခုသို့ ဒေတာ megabytes ကို ရေးမှတ်စေနိုင်သည်။ ကျွန်တော် နားလည်သလောက် ပြဿနာရဲ့ အဖြေပါ။ က material၊ သည် database နှင့် အလုပ်အား asynchronous background tasks သို့ ရွှေ့ရန်ဖြစ်သည်။ ဆိုလိုသည်မှာ Firefox သည် အမှန်တကယ်လိုအပ်သည်ထက် ပိုမိုတင်းကြပ်သောသိုလှောင်မှုတည်မြဲမှုလိုအပ်ချက်များကိုအကောင်အထည်ဖော်ရန်အသုံးပြုခဲ့ပြီး ext3 ဖိုင်စနစ်အင်္ဂါရပ်များကသာ ဤပြဿနာကိုပိုမိုဆိုးရွားစေသည်။

ဒုတိယပြဿနာက 2009 မှာဖြစ်ခဲ့တယ်။ ထို့နောက်၊ စနစ်ပျက်ကျပြီးနောက်၊ အသစ်ဖန်တီးထားသောဖိုင်များစွာသည် သုည-အရှည်ဖြစ်သည်ဟူသောအချက်နှင့် ext4 ဖိုင်စနစ်အသစ်၏အသုံးပြုသူများသည် ကြုံတွေ့ခဲ့ရသော်လည်း၊ ၎င်းသည် ext3 ဖိုင်စနစ်ဟောင်းတွင် ဖြစ်မလာပါ။ ယခင်စာပိုဒ်တွင်၊ ext3 သည် အရာများစွာကို နှေးကွေးစေသည့် disk ပေါ်ရှိ ဒေတာများစွာကို မည်ကဲ့သို့ စွန့်ပစ်ခဲ့သည်ကို ပြောပြခဲ့သည်။ fsync(). အခြေအနေတိုးတက်စေရန်၊ ext4 သည် သီးခြားဖိုင်တစ်ခုနှင့်သက်ဆိုင်သည့် "ညစ်ပတ်သော" စာမျက်နှာများကိုသာ ဖယ်ရှားပေးသည်။ အခြားဖိုင်များ၏ ဒေတာများသည် ext3 ထက် အချိန်ပိုကြာစွာ မှတ်ဉာဏ်ထဲတွင် ရှိနေသည်။ စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန် ၎င်းကို လုပ်ဆောင်ခဲ့သည် (ပုံမှန်အားဖြင့်၊ ဒေတာသည် ဤအခြေအနေတွင် စက္ကန့် 30 ကြာနေမည်ဖြစ်ပြီး၊ ၎င်းကို အသုံးပြု၍ သင် configure လုပ်နိုင်ပါသည်။ dirty_expire_centisecs; ဒီမှာ ဤအကြောင်းအရာနှင့် ပတ်သက်၍ သင်ပိုမိုသိရှိနိုင်သည်)။ ဆိုလိုသည်မှာ ပျက်စီးမှုတစ်ခုပြီးနောက် ဒေတာအများအပြား ဆုံးရှုံးသွားနိုင်သည်။ ဤပြဿနာအတွက် ဖြေရှင်းနည်းမှာ အသုံးပြုရန်ဖြစ်သည်။ fsync() တည်ငြိမ်သောဒေတာသိုလှောင်မှုကိုပေးဆောင်ရန်နှင့်မအောင်မြင်မှုများ၏အကျိုးဆက်များမှတတ်နိုင်သမျှကာကွယ်ရန်လိုအပ်သော application များတွင်။ လုပ်ဆောင်ချက် fsync() ext4 နဲ့ ext3 ထက် အများကြီး ပိုထိရောက်တယ်။ ဤချဉ်းကပ်မှု၏အားနည်းချက်မှာ ယခင်ကကဲ့သို့ ၎င်း၏အသုံးပြုမှုသည် ပရိုဂရမ်များထည့်သွင်းခြင်းကဲ့သို့သော လုပ်ဆောင်ချက်အချို့ကို နှေးကွေးစေခြင်းပင်ဖြစ်သည်။ ဒီအကြောင်းအသေးစိတ်ကြည့်ပါ။ ဒီမှာ и ဒီမှာ.

တတိယပြဿနာ fsync(), 2018 တွင်စတင်ခဲ့သည်။ ထို့နောက် PostgreSQL ပရောဂျက်၏ဘောင်အတွင်းတွင်၊ ၎င်းသည် function ကိုတွေ့ရှိခဲ့သည်။ fsync() error ကြုံတွေ့ရပြီး ၎င်းသည် "ညစ်ပတ်သော" စာမျက်နှာများကို "သန့်ရှင်း" အဖြစ် အမှတ်အသားပြုပါသည်။ ထို့ကြောင့် အောက်ပါခေါ်ဆိုမှုများ fsync() အဲဒီလို စာမျက်နှာတွေနဲ့ ဘာမှ မလုပ်ပါနဲ့။ ထို့အတွက်ကြောင့် ပြုပြင်ထားသော စာမျက်နှာများကို မှတ်ဉာဏ်တွင် သိမ်းဆည်းထားပြီး ဒစ်ခ်သို့ ဘယ်သောအခါမှ မရေးပါ။ ဒေတာအချို့ကို ဒစ်ခ်သို့ ရေးချသည်ဟု အပလီကေးရှင်းက ယူဆသောကြောင့် ၎င်းသည် တကယ့်ဘေးဒုက္ခတစ်ခုဖြစ်သော်လည်း၊ အမှန်တကယ်တော့ ထိုသို့ဖြစ်မည်မဟုတ်ပေ။ အဲဒီလို ပျက်ကွက်တယ်။ fsync() ရှားပါတယ်၊ ဒီလိုအခြေအနေမျိုးမှာ application က ပြဿနာကို တိုက်ဖျက်ဖို့ ဘာမှနီးပါး မလုပ်နိုင်ပါဘူး။ ဒီရက်ပိုင်းမှာ ဒီလိုဖြစ်လာတဲ့အခါ PostgreSQL နဲ့ တခြား application တွေ ပျက်စီးသွားတယ်။ ဒါဟာဖြစ်ပါတယ်"Applications များသည် fsync Failures မှ ပြန်လည်ရယူနိုင်သလား" ဆောင်းပါးတွင်၊ ဤပြဿနာကို အသေးစိတ်လေ့လာထားသည်။ လောလောဆယ် ဤပြဿနာအတွက် အကောင်းဆုံးဖြေရှင်းချက်မှာ Direct I/O ကို အလံဖြင့် အသုံးပြုရန်ဖြစ်သည်။ O_SYNC သို့မဟုတ် အလံနှင့် O_DSYNC. ဤချဉ်းကပ်မှုဖြင့်၊ စနစ်သည် သီးခြားဒေတာရေးခြင်းဆိုင်ရာ လုပ်ဆောင်ချက်များကို လုပ်ဆောင်ရာတွင် ဖြစ်ပေါ်လာနိုင်သည့် အမှားအယွင်းများကို အစီရင်ခံမည်ဖြစ်သော်လည်း၊ ဤချဉ်းကပ်မှုတွင် အက်ပ်လီကေးရှင်းသည် ကြားခံများကို စီမံခန့်ခွဲရန် လိုအပ်သည်။ ၎င်းအကြောင်းပိုမိုဖတ်ပါ။ ဒီမှာ и ဒီမှာ.

O_SYNC နှင့် O_DSYNC အလံများကို အသုံးပြု၍ ဖိုင်များကိုဖွင့်ခြင်း။

ယန္တရားများအကြောင်း ဆွေးနွေးမှုသို့ ပြန်သွားကြပါစို့ Linuxတည်ငြိမ်သောဒေတာသိုလှောင်မှုကိုသေချာစေသည်။ အထူးသဖြင့်၊ ကျွန်ုပ်တို့သည် အလံအသုံးပြုမှုအကြောင်း ပြောနေပါသည် O_SYNC သို့မဟုတ် အလံ O_DSYNC စနစ်ခေါ်ဆိုမှုကို အသုံးပြု၍ ဖိုင်များကိုဖွင့်သည့်အခါ open(). ဤချဉ်းကပ်မှုဖြင့်၊ ဒေတာတစ်ခုစီကို ကွန်မန့်တစ်ခုစီပြီးနောက် လုပ်ဆောင်သကဲ့သို့ လုပ်ဆောင်သည်။ write() စနစ်သည် အသီးသီး အမိန့်ပေးသည်။ fsync() и fdatasync()။ အဆိုပါ POSIX သတ်မှတ်ချက်များ ၎င်းကို "Synchronized I/O File Integrity Completion" နှင့် "Data Integrity Completion" ဟုခေါ်သည်။ ဤချဉ်းကပ်မှု၏ အဓိကအားသာချက်မှာ ဒေတာခိုင်မာမှုရှိစေရန် စနစ်ခေါ်ဆိုမှုတစ်ခုတည်းကိုသာ လုပ်ဆောင်ရန် လိုအပ်ပြီး နှစ်ခုမဟုတ်ပါ (ဥပမာ- write() и fdatasync()) ဤချဉ်းကပ်မှု၏ အဓိကအားနည်းချက်မှာ သက်ဆိုင်ရာ file descriptor ကိုအသုံးပြု၍ ရေးသားခြင်းလုပ်ငန်းအားလုံးကို တစ်ပြိုင်တည်းလုပ်ဆောင်မည်ဖြစ်ပြီး၊ ၎င်းသည် အပလီကေးရှင်းကုဒ်ကို တည်ဆောက်နိုင်မှုကို ကန့်သတ်နိုင်သည်။

O_DIRECT အလံဖြင့် တိုက်ရိုက် I/O ကို အသုံးပြုခြင်း။

စနစ်ခေါ်ဆိုမှု open() အလံကိုထောက်ခံပါတယ်။ O_DIRECTလည်ပတ်မှုစနစ် ကက်ရှ်ကို ကျော်ဖြတ်ရန်၊ I/O လုပ်ဆောင်ချက်များကို လုပ်ဆောင်ရန်၊ ဒစ်ခ်နှင့် တိုက်ရိုက်အပြန်အလှန်လုပ်ဆောင်ရန် ဒီဇိုင်းပြုလုပ်ထားသည်။ ဤအရာသည် များစွာသောကိစ္စများတွင် ပရိုဂရမ်မှထုတ်ပေးသော write commands များကို disk နှင့်အလုပ်လုပ်ရန်ရည်ရွယ်သော command များအဖြစ် တိုက်ရိုက်ဘာသာပြန်ခြင်းကို ဆိုလိုသည်။ သို့သော် ယေဘုယျအားဖြင့် ဤယန္တရားသည် လုပ်ငန်းဆောင်တာများအတွက် အစားထိုးမှုမဟုတ်ပါ။ fsync() သို့မဟုတ် fdatasync(). အမှန်မှာ disk ကိုယ်တိုင်လုပ်နိုင်သည်။ နှောင့်နှေးသို့မဟုတ် cache အချက်အလက်ရေးသားရန်အတွက် သင့်လျော်သော command များ။ ပိုဆိုးသည်မှာ အချို့သော အထူးကိစ္စများတွင် I/O လုပ်ဆောင်ချက်များသည် အလံကိုအသုံးပြုသည့်အခါ လုပ်ဆောင်သည်။ O_DIRECT, ထုတ်လွှင့်သည်။ ရိုးရာ buffered operations ထဲသို့။ ဤပြဿနာကိုဖြေရှင်းရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ ဖိုင်များကိုဖွင့်ရန် အလံကိုအသုံးပြုခြင်းဖြစ်သည်။ O_DSYNCဆိုလိုသည်မှာ စာရေးခြင်းလုပ်ငန်းတစ်ခုစီသည် ခေါ်ဆိုမှုတစ်ခုဖြင့် လုပ်ဆောင်သွားမည်ဖြစ်သည်။ fdatasync().

XFS ဖိုင်စနစ်သည် မကြာသေးမီက "fast path" ကို ထည့်သွင်းခဲ့ကြောင်း တွေ့ရှိရပါသည်။ O_DIRECT|O_DSYNC- ဒေတာမှတ်တမ်းများ။ အကယ်၍ block ကိုအသုံးပြု၍ overwrite လုပ်ပါ။ O_DIRECT|O_DSYNCထို့နောက် XFS သည် ကက်ရှ်ကို ဖယ်ရှားခြင်းအစား၊ စက်က ၎င်းကို ပံ့ပိုးပါက FUA ရေးသားသည့် အမိန့်ကို လုပ်ဆောင်မည်ဖြစ်သည်။ utility ကို အသုံးပြု၍ ၎င်းကို ငါစစ်ဆေးခဲ့သည်။ blktrace စနစ်အတွက် Linux 5.4 /Ubuntu ၂၀.၀၄။ ဒီနည်းလမ်းက ပိုထိရောက်သင့်ပါတယ်၊ ဘာလို့လဲဆိုတော့ ဒစ်ခ်ထဲကို အနည်းဆုံးဒေတာတွေရေးပြီး နှစ်ခုလုပ်မယ့်အစား တစ်ခုတည်းကိုပဲသုံးလို့ပါ (ကက်ရှ်ကိုရေးပြီး ဖလပ်လုပ်ခြင်း)။ လင့်ခ်တစ်ခုတွေ့လိုက်တယ်။ ကွမ်းခြံကုန်း ဤယန္တရားကိုအကောင်အထည်ဖော်သော 2018 kernel။ ဤ optimization ကိုအခြားဖိုင်စနစ်များတွင်အသုံးပြုခြင်းနှင့် ပတ်သက်၍ ဆွေးနွေးမှုအချို့ရှိပါသည်၊ သို့သော်ကျွန်ုပ်သိသလောက် XFS သည်၎င်းကိုယခုအချိန်အထိထောက်ပံ့ပေးသောတစ်ခုတည်းသောဖိုင်စနစ်ဖြစ်သည်။

sync_file_range() လုပ်ဆောင်ချက်

В Linux စနစ်ခေါ်ဆိုမှုတစ်ခုရှိတယ် sync_file_range()၎င်းသည် ဖိုင်တစ်ခုလုံးကိုမဟုတ်ဘဲ ဖိုင်တစ်ပိုင်းကိုသာ ဒစ်ခ်သို့ ဖယ်ရှားနိုင်စေပါသည်။ ဤခေါ်ဆိုမှုသည် ချိန်ကိုက်မှုတစ်ခုအား စတင်ပြီး ပြီးမြောက်ရန် မစောင့်ပါ။ ရည်ညွှန်းချက်၌ကား၊ sync_file_range() ဤအမိန့်သည် "အလွန်အန္တရာယ်များ" ဟုဆိုသည်။ ၎င်းကိုအသုံးပြုရန်မအကြံပြုပါ။ အင်္ဂါရပ်များနှင့်အန္တရာယ်များ sync_file_range() အလွန်ကောင်းမွန်စွာ ဖော်ပြထားပါသည်။ ဤ ပစ္စည်း အထူးသဖြင့်၊ ဤခေါ်ဆိုမှုသည် kernel မှ "ညစ်ပတ်သော" ဒေတာကို disk သို့ဖယ်ရှားသည့်အခါ ထိန်းချုပ်ရန် RocksDB ကိုအသုံးပြုပုံရသည်။ သို့သော် တစ်ချိန်တည်းတွင် တည်ငြိမ်သောဒေတာသိမ်းဆည်းမှုသေချာစေရန် ၎င်းကိုလည်းအသုံးပြုသည်။ fdatasync()။ အဆိုပါ ကုဒ် RocksDB တွင် ဤအကြောင်းအရာနှင့် ပတ်သက်၍ စိတ်ဝင်စားဖွယ် မှတ်ချက်အချို့ရှိသည်။ ဥပမာ၊ ခေါ်ဆိုပုံရသည်။ sync_file_range() ZFS ကိုအသုံးပြုသောအခါတွင်ဒေတာကို disk သို့မထုတ်ပါ။ အသုံးပြုခဲသောကုဒ်တွင် ချွတ်ယွင်းချက်များ ပါဝင်နိုင်သည်ဟု အတွေ့အကြုံက ပြောပြသည်။ ထို့ကြောင့်၊ လုံးဝမလိုအပ်ဘဲ ဤစနစ်ခေါ်ဆိုခြင်းကို အသုံးပြုခြင်းမပြုရန် ကျွန်ုပ်အကြံပြုလိုပါသည်။

ဒေတာဆက်မြဲမှုရှိစေရန်အတွက် စနစ်ခေါ်ဆိုမှုများ

အမြဲမပြတ် I/O လုပ်ဆောင်ချက်များကို လုပ်ဆောင်ရန် ချဉ်းကပ်မှု သုံးခုရှိကြောင်း ကျွန်ုပ် နိဂုံးချုပ်လိုက်ပါသည်။ ၎င်းတို့အားလုံးသည် function call တစ်ခုလိုအပ်သည်။ fsync() ဖိုင်ကိုဖန်တီးခဲ့သည့်လမ်းညွှန်အတွက်။ ချဉ်းကပ်ပုံများမှာ-

1. လုပ်ဆောင်ချက်ခေါ်ဆိုမှု fdatasync() သို့မဟုတ် fsync() function ပြီးနောက် write() (သုံးရင် ပိုကောင်းပါတယ်။ fdatasync()).
2. အလံတစ်ခုဖြင့်ဖွင့်ထားသော ဖိုင်ဖော်ပြချက်တစ်ခုနှင့် အလုပ်လုပ်ခြင်း။ O_DSYNC သို့မဟုတ် O_SYNC (အလံနှင့် ပိုကောင်းသည်။ O_DSYNC).
3. ညွှန်ကြားချက်အသုံးပြုမှု pwritev2() အလံနှင့်အတူ RWF_DSYNC သို့မဟုတ် RWF_SYNC (ဖြစ်နိုင်ရင် အလံနဲ့ RWF_DSYNC).

စွမ်းဆောင်ရည်မှတ်စုများ

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

1. ဖိုင်ဒေတာကို ထပ်ရေးခြင်းသည် ဖိုင်တစ်ခုသို့ ဒေတာထပ်ထည့်ခြင်းထက် ပိုမြန်သည် (စွမ်းဆောင်ရည်ရရှိမှုသည် 2-100%) ရှိနိုင်ပါသည်။ ဖိုင်တစ်ခုသို့ ဒေတာကို တွဲချိတ်ခြင်းသည် စနစ်ခေါ်ဆိုပြီးနောက်တွင်ပင် ဖိုင်၏ မက်တာဒေတာကို ထပ်လောင်းပြောင်းလဲမှု လိုအပ်ပါသည်။ fallocate()သို့သော် ဤအကျိုးသက်ရောက်မှုပမာဏ ကွဲပြားနိုင်သည်။ အကောင်းဆုံးစွမ်းဆောင်ရည်အတွက် ဖုန်းခေါ်ဆိုရန် အကြံပြုအပ်ပါသည်။ fallocate() လိုအပ်သောနေရာကို ကြိုတင်ခွဲဝေပေးရန်။ ထို့နောက် ဤနေရာကို သုညဖြင့် အတိအလင်းဖြည့်ပြီး ခေါ်ရပါမည်။ fsync(). ၎င်းသည် ဖိုင်စနစ်ရှိ ဆက်စပ်ပိတ်ဆို့မှုများကို "ခွဲဝေမထားသော" အစား "ခွဲဝေသတ်မှတ်ခြင်း" အဖြစ် အမှတ်အသားပြုစေမည်ဖြစ်သည်။ ၎င်းသည် စွမ်းဆောင်ရည် အနည်းငယ် (2%) ခန့် တိုးတက်မှုကို ပေးသည်။ ထို့အပြင်၊ အချို့သောဒစ်များသည် အခြားအရာများထက် ပထမဘလောက်ဝင်ရောက်လည်ပတ်မှု နှေးကွေးသွားနိုင်သည်။ ဆိုလိုသည်မှာ နေရာကို သုညဖြင့် ဖြည့်သွင်းခြင်းဖြင့် သိသာထင်ရှားသော (100%) စွမ်းဆောင်ရည် တိုးတက်မှုကို ဖြစ်ပေါ်စေနိုင်သည်။ အထူးသဖြင့်၊ ၎င်းသည် disks များနှင့်ဖြစ်ပွားနိုင်သည်။ AWS EBS (ဒါကတရားဝင်မဟုတ်တဲ့အချက်အလက်ပါ၊ ငါသူတို့ကိုအတည်မပြုနိုင်ဘူး)။ Storage မှာလည်း အလားတူပါပဲ။ GCP Persistent Disk (၎င်းသည် တရားဝင်အချက်အလက်ဖြစ်ပြီး၊ စမ်းသပ်မှုများဖြင့် အတည်ပြုပြီးသားဖြစ်သည်)။ တခြား ပညာရှင်တွေလည်း ဒီလိုပါပဲ။ လေ့လာရေးမတူညီသော disk များနှင့်သက်ဆိုင်သည်။
2. စနစ်ခေါ်ဆိုမှု နည်းပါးလေ၊ စွမ်းဆောင်ရည် မြင့်မားလေ (အမြတ် 5%) ခန့် ရှိနိုင်ပါသည်။ ခေါ်ပုံရသည်။ open() အလံနှင့်အတူ O_DSYNC သို့မဟုတ် ဖုန်းခေါ်ဆိုပါ။ pwritev2() အလံနှင့်အတူ RWF_SYNC မြန်မြန်ခေါ်ပါ။ fdatasync(). ဤနေရာတွင် အဓိကအချက်မှာ ဤချဉ်းကပ်မှုဖြင့်၊ တူညီသောလုပ်ငန်းတာဝန်ကိုဖြေရှင်းရန် (ခေါ်ဆိုမှုနှစ်ခုအစား ခေါ်ဆိုမှုတစ်ခုအစား) နည်းပါးသောစနစ်ခေါ်ဆိုမှုများ လုပ်ဆောင်ရမည်ဟု ကျွန်ုပ်သံသယရှိပါသည်။ သို့သော် စွမ်းဆောင်ရည်ကွာခြားချက်မှာ အလွန်သေးငယ်သောကြောင့် သင်သည် ၎င်းကို အလွယ်တကူ လျစ်လျူရှုနိုင်ပြီး ၎င်း၏ယုတ္တိဗေဒ၏ ရှုပ်ထွေးမှုကို မဖြစ်ပေါ်စေသည့် အပလီကေးရှင်းတွင် တစ်ခုခုကို အသုံးပြုနိုင်သည်။

ရေရှည်တည်တံ့သော ဒေတာသိမ်းဆည်းခြင်းဆိုင်ရာ ခေါင်းစဉ်ကို သင်စိတ်ဝင်စားပါက၊ ဤအရာများသည် အသုံးဝင်သော ပစ္စည်းအချို့ဖြစ်သည်။

• I/O အသုံးပြုခွင့်နည်းလမ်းများ - အဝင်/အထွက် ယန္တရားများ၏ အခြေခံ ခြုံငုံသုံးသပ်ချက်။
• ဒေတာ ဒစ်ခ်သို့ ရောက်ရှိကြောင်း သေချာစေပါသည်။ - အပလီကေးရှင်းမှဒစ်သို့သွားရာလမ်းရှိဒေတာများဖြစ်ပျက်ပုံအကြောင်းဇာတ်လမ်း။
• ပါဝင်သောလမ်းညွှန်ကို မည်သည့်အချိန်တွင် စင့်ခ်လုပ်သင့်သနည်း။ - လျှောက်ထားရမည့်အချိန်၏မေးခွန်း၏အဖြေ fsync() လမ်းညွှန်များအတွက်။ အတိုချုပ်ပြောရလျှင် ဖိုင်အသစ်တစ်ခုဖန်တီးသည့်အခါ ဤသို့ပြုလုပ်သင့်ပြီး ဤအကြံပြုချက်အတွက် အကြောင်းရင်းမှာ Linux ဖိုင်တစ်ခုတည်းသို့ လင့်ခ်များစွာ ရှိနိုင်ပါသည်။
• SQL Server ဖွင့်ထားသည် Linux: FUA အတွင်းပိုင်း — ဤနေရာတွင် ပလက်ဖောင်းပေါ်ရှိ SQL Server တွင် persistent data storage ကို မည်သို့အကောင်အထည်ဖော်သည်ကို ဖော်ပြထားပါသည် Linuxဤနေရာတွင် စနစ်ခေါ်ဆိုမှုများအကြား စိတ်ဝင်စားဖွယ်ကောင်းသော နှိုင်းယှဉ်ချက်အချို့ရှိပါသည်။ Windows и LinuxXFS ရဲ့ FUA optimization အကြောင်း ကျွန်တော် သင်ယူခဲ့တာ ဒီပစ္စည်းကြောင့်ပဲဆိုတာ သေချာပါတယ်။

ဒစ်ပေါ်တွင် လုံခြုံစွာသိမ်းဆည်းထားသည်ဟု သင်ထင်ထားသည့် ဒေတာများ ဆုံးရှုံးဖူးပါသလား။

source: www.habr.com