ကျွန်ုပ်၏ NVMe သည် ကျွန်ုပ်၏ SSD ထက် အဘယ်ကြောင့်နှေးသနည်း။

ဤဆောင်းပါးတွင် I/O စနစ်ခွဲ၏ ကွဲပြားချက်အချို့နှင့် စွမ်းဆောင်ရည်အပေါ် ၎င်းတို့၏သက်ရောက်မှုများကို လေ့လာပါမည်။

လွန်ခဲ့သည့် ရက်သတ္တပတ်အနည်းငယ်က ဆာဗာတစ်ခုရှိ NVMe သည် အခြားတစ်ခုရှိ SATA ထက် အဘယ်ကြောင့်နှေးသနည်းဟူသောမေးခွန်းနှင့် ရင်ဆိုင်ခဲ့ရသည်။ ကျွန်ုပ်သည် ဆာဗာသတ်မှတ်ချက်များကို ကြည့်ရှုပြီး ဤမေးခွန်းသည် ရှုပ်ထွေးသောမေးခွန်းဖြစ်ကြောင်း သဘောပေါက်ခဲ့သည်- NVMe သည် အသုံးပြုသူအပိုင်းမှဖြစ်ပြီး SSD သည် ဆာဗာအပိုင်းမှဖြစ်သည်။

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

fsync ဆိုတာ ဘာလဲ၊ ဘယ်နေရာမှာ သုံးတာလဲ။

drives များနှင့်အလုပ်လုပ်ခြင်းကို အရှိန်မြှင့်ရန်အတွက်၊ ဆိုလိုသည်မှာ၊ တည်ငြိမ်သော memory တွင် သိမ်းဆည်းထားသော data သည် buffer ၏ contents များကို drive တွင်သိမ်းဆည်းရန် အဆင်ပြေသောအခွင့်အရေးတစ်ခုပေါ်လာသည်အထိဖြစ်သည်။ "အခွင့်အလမ်း" အတွက်စံနှုန်းများကိုလည်ပတ်မှုစနစ်နှင့် drive ၏ဝိသေသလက္ခဏာများဖြင့်ဆုံးဖြတ်သည်။ ပါဝါချို့ယွင်းသောအခါ၊ ကြားခံရှိဒေတာအားလုံး ဆုံးရှုံးသွားပါမည်။

ဖိုင်တစ်ခုသို့ ပြောင်းလဲမှုများကို အလယ်အလတ်ကြားခံတွင်မဟုတ်ဘဲ drive သို့ရေးထားကြောင်း သေချာစေရန်အတွက် လုပ်ဆောင်စရာများစွာရှိပါသည်။ POSIX-ကိုက်ညီသော fsync စနစ်ခေါ်ဆိုမှုကို အသုံးပြုခြင်းဖြင့် ဤအာမခံချက်ကို ရယူနိုင်ပါသည်။ fsync ကိုခေါ်ဆိုခြင်းသည် ကြားခံမှ drive သို့ စာရေးခိုင်းသည်။

C တွင်တိုတောင်းသောပရိုဂရမ်ပုံစံဖြင့် buffers ၏အကျိုးသက်ရောက်မှုကို အတုအယောင်ဥပမာတစ်ခုဖြင့် သရုပ်ပြကြပါစို့။

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /* Открываем файл answer.txt на запись, если его нет -- создаём */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /* Записываем первый набор данных */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /* Делаем вид, что проводим вычисления в течение 10 секунд */
    sleep(10);
    /* Записываем результат вычислений */
    write(fd, "42n", 3); 

    return 0;
}

မှတ်ချက်များသည် ပရိုဂရမ်ရှိ လုပ်ဆောင်ချက်များကို ကောင်းစွာရှင်းပြသည်။ "ဘဝ၏အဓိကမေးခွန်း၏အဖြေ၊ စကြဝဠာနှင့်အရာအားလုံး" ဟူသောစာသားကို operating system မှကန့်လန့်ခံမည်ဖြစ်ပြီး၊ "တွက်ချက်မှုများ" အတွင်းပြန်လည်သတ်မှတ်ရန်ခလုတ်ကိုနှိပ်ခြင်းဖြင့်ဆာဗာကိုပြန်လည်စတင်ပါက၊ ဖိုင်သည်ဗလာဖြစ်လိမ့်မည်။ ကျွန်ုပ်တို့၏ဥပမာတွင်၊ စာသားဆုံးရှုံးမှုသည် ပြဿနာမဟုတ်ပါ၊ ထို့ကြောင့် fsync မလိုအပ်ပါ။ ဒေတာဘေ့စ်များသည် ဤအကောင်းမြင်မှုကို မမျှဝေပါ။

ဒေတာဘေ့စ်များသည် ဖိုင်များစွာနှင့် တပြိုင်နက်အလုပ်လုပ်သည့် ရှုပ်ထွေးသောပရိုဂရမ်များဖြစ်သောကြောင့် ၎င်းတို့ရေးသောဒေတာကို drive တွင် သိမ်းဆည်းမည်ဖြစ်ကြောင်း သေချာစေလိုသောကြောင့် database အတွင်းရှိ ဒေတာများ၏ ညီညွတ်မှုသည် ၎င်းအပေါ်တွင်မူတည်သောကြောင့် ၎င်းတို့ရေးသားသည့်ဒေတာကို drive တွင်သိမ်းဆည်းမည်ဖြစ်ကြောင်း သေချာစေလိုပါသည်။ ဒေတာဘေ့စ်များသည် ပြီးမြောက်သော လွှဲပြောင်းမှုများအားလုံးကို မှတ်တမ်းတင်ရန်နှင့် အချိန်မရွေး ပါဝါဆုံးရှုံးရန် အသင့်ဖြစ်ရန် ဒီဇိုင်းထုတ်ထားသည်။ ဤအပြုအမူသည် fsync ကို အမြောက်အမြား အဆက်မပြတ် အသုံးပြုရန် လိုအပ်သည်။

fsync ကို မကြာခဏ အသုံးပြုခြင်း၏ အကျိုးသက်ရောက်မှုသည် အဘယ်နည်း။

သာမာန် I/O ကာလအတွင်း၊ လည်ပတ်မှုစနစ်သည် ပြင်ပဒရိုက်များကို မန်မိုရီအဆင့်တွင် အနှေးဆုံးဖြစ်သောကြောင့်၊ လည်ပတ်မှုစနစ်သည် ဒစ်ခ်များနှင့် ဆက်သွယ်မှုကို အကောင်းဆုံးဖြစ်အောင် ကြိုးစားသည်။ ထို့ကြောင့်၊ လည်ပတ်မှုစနစ်သည် drive သို့ဝင်ရောက်ခွင့်တစ်ခုတွင် တတ်နိုင်သမျှ data များရေးရန်ကြိုးစားသည်။

တိကျသောဥပမာတစ်ခုဖြင့် fsync အသုံးပြုခြင်း၏အကျိုးသက်ရောက်မှုကို သရုပ်ပြကြပါစို့။ ကျွန်ုပ်တို့တွင် စမ်းသပ်ဒရိုက်များအဖြစ် အောက်ပါ SSD များရှိသည်။

• Intel® DC SSD S4500 480 GB၊ SATA 3.2၊ 6 Gbit/s၊
• Samsung 970 EVO Plus 500GB၊ PCIe 3.0 x4၊ ~31 Gbit/s မှတစ်ဆင့် ချိတ်ဆက်ထားသည်။

စစ်ဆေးမှုများကို Ubuntu 2255 အသုံးပြုသည့် Intel® Xeon® W-20.04 တွင် ပြုလုပ်သည်။ Sysbench 1.0.18 ကို disks များကိုစမ်းသပ်ရန်အသုံးပြုသည်။ အပိုင်းတစ်ခုကို ext4 အဖြစ် ဖော်မတ်လုပ်ထားသည့် disk များပေါ်တွင် အပိုင်းတစ်ခုကို ဖန်တီးထားသည်။ စမ်းသပ်မှုအတွက် ပြင်ဆင်ရာတွင် 100 GB ဖိုင်များ ဖန်တီးခြင်း ပါဝင်သည်-

sysbench --test=fileio --file-total-size=100G prepare

စမ်းသပ်မှုများ

# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

စာမေးပွဲရလဒ်များကို ဇယားတွင် ဖော်ပြထားသည်။

စမ်းသပ်
Intel® S4500
Samsung 970 EVO+

fsync, MiB/s မပါဘဲ စာဖတ်ခြင်း။
5734.89
9028.86

fsync, MiB/s မပါဘဲ အသံသွင်းခြင်း။
3823.26
6019.24

fsync, MiB/s ဖြင့် ဖတ်ခြင်း။
37.76
3.27

fsync, MiB/s ဖြင့် မှတ်တမ်းတင်ခြင်း။
25.17
2.18

လည်ပတ်မှုစနစ်ကိုယ်တိုင်က disks များနှင့်မည်သို့အလုပ်လုပ်ရမည်ကိုဆုံးဖြတ်ပြီး fsync ကိုအသုံးပြုသည့်အခါတွင်ဆုံးရှုံးသွားသောအခါ client အပိုင်းမှ NVMe သည်ယုံကြည်စိတ်ချစွာဦးဆောင်နေကြောင်းကိုမြင်ရလွယ်ကူသည်။ ယင်းက မေးခွန်းနှစ်ခုကို ဖြစ်ပေါ်စေသည်-

1. fsync မပါဘဲ စမ်းသပ်မှုတွင် ဖတ်ရှုနှုန်းသည် ချန်နယ်၏ ရုပ်ပိုင်းဆိုင်ရာ လှိုင်းနှုန်းထက် အဘယ်ကြောင့် ကျော်လွန်သနည်း။
2. fsync တောင်းဆိုချက်အများအပြားကို ကိုင်တွယ်ရာတွင် ဆာဗာအပိုင်း SSD သည် အဘယ်ကြောင့် ပိုမိုကောင်းမွန်သနည်း။

ပထမမေးခွန်းအတွက် အဖြေက ရိုးရှင်းသည်- sysbench သည် သုညနှင့် ပြည့်နေသော ဖိုင်များကို ထုတ်ပေးသည်။ ထို့ကြောင့် သုည 100 ဂစ်ဂါဘိုက်ကျော်ကို စမ်းသပ်ခဲ့သည်။ ဒေတာသည် အလွန်တူညီပြီး ကြိုတင်မှန်းဆနိုင်သောကြောင့်၊ OS အမျိုးမျိုးကို ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်မှုများသည် ပါဝင်လာပြီး လုပ်ဆောင်မှုကို သိသိသာသာ မြန်ဆန်စေသည်။

sysbench ရလဒ်အားလုံးကို သင်မေးခွန်းထုတ်ပါက၊ သင်သည် fio ကိုသုံးနိုင်သည်။

# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

စမ်းသပ်
Intel® S4500
Samsung 970 EVO+

fsync, MiB/s မပါဘဲ စာဖတ်ခြင်း။
45.5
178

fsync, MiB/s မပါဘဲ အသံသွင်းခြင်း။
30.4
119

fsync, MiB/s ဖြင့် ဖတ်ခြင်း။
32.6
20.9

fsync, MiB/s ဖြင့် မှတ်တမ်းတင်ခြင်း။
21.7
13.9

fsync ကိုအသုံးပြုသောအခါ NVMe စွမ်းဆောင်ရည်ကျဆင်းသွားသည့်သဘောထားကို ရှင်းရှင်းလင်းလင်းမြင်ရသည်။ ဒုတိယမေးခွန်းကိုဖြေဖို့ သင်ဆက်သွားနိုင်ပါတယ်။

ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း သို့မဟုတ် မှုန်ဝါးခြင်း

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

• အစီအစဉ်;
• ဟာ့ဒ်ဝဲ။

software buffer သည် operating system တွင်ရှိသော buffers များကို ရည်ညွှန်းပြီး hardware buffer သည် disk controller ၏ မတည်ငြိမ်သော memory ကို ရည်ညွှန်းသည်။ fsync စနစ်ခေါ်ဆိုမှုသည် ၎င်း၏ကြားခံမှ ပင်မသိုလှောင်မှုသို့ ဒေတာများရေးရန် drive သို့ အမိန့်တစ်ခုပေးပို့သော်လည်း အမိန့်ကို မှန်ကန်စွာလုပ်ဆောင်ကြောင်း အတည်ပြုရန်နည်းလမ်းမရှိပါ။

SSD သည် အကောင်းဆုံးရလဒ်များကိုပြသသောကြောင့်၊ ယူဆချက်နှစ်ခုကို ပြုလုပ်နိုင်သည်-

• disk ကို အလားတူဝန်အတွက် ဒီဇိုင်းထုတ်ထားသည်။
• disk "bluffs" နှင့် command ကိုလျစ်လျူရှု။

ပါဝါဆုံးရှုံးမှုစမ်းသပ်မှုပြုလုပ်ပါက drive ၏မရိုးသားသောအပြုအမူကိုသတိပြုမိနိုင်သည်။ ဒါကို script နဲ့ စစ်ဆေးနိုင်ပါတယ်။ diskchecker.pl, အဲဒါ ထူထောင် 2005 နှစျတှငျ။

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

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

ဇာတ်ညွှန်းကို run ပြီးနောက်၊ သင်သည် "client" သို့ ပါဝါပိတ်ပြီး ပါဝါကို မိနစ်အတော်ကြာအောင် မပြန်ပါနှင့်။ ပြင်းထန်စွာ ပိတ်ထားရုံတင်မဟုတ်ဘဲ လျှပ်စစ်ဓာတ်အား စမ်းသပ်နေသူအား အဆက်ဖြတ်ရန် အရေးကြီးပါသည်။ အချိန်အတော်ကြာပြီးနောက်၊ ဆာဗာကို ချိတ်ဆက်ပြီး OS တွင် တင်နိုင်သည်။ OS ကို တင်ပြီးနောက် ၎င်းကို ထပ်မံစတင်ရန် လိုအပ်သည်။ diskchecker.plအငြင်းအခုံတစ်ခုနှင့် အတည်ပြုရန်.

./diskchecker.pl -s <server[:port]> verify <file>

စစ်ဆေးမှုအဆုံးတွင် အမှားအယွင်းအရေအတွက်ကို တွေ့ရပါမည်။ 0 ရှိလျှင် disk သည်စမ်းသပ်မှုအောင်မြင်သည်။ ဒစ်အတွက် ကံကောင်းသော တိုက်ဆိုင်မှုကို ဖယ်ထုတ်ရန်၊ စမ်းသပ်မှုကို အကြိမ်များစွာ ထပ်ခါထပ်ခါ ပြုလုပ်နိုင်သည်။

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

ကောက်ချက်

ဒစ်ခ်များ သို့မဟုတ် အဆင်သင့်လုပ်ထားသော ဖွဲ့စည်းမှုပုံစံများ တစ်ခုလုံးကို ရွေးချယ်သည့်အခါ၊ ဖြေရှင်းရန် လိုအပ်သည့် ပြဿနာများ၏ အတိအကျကို မှတ်သားထားသင့်သည်။ ပထမတစ်ချက်တွင်၊ PCIe မျက်နှာပြင်ပါရှိသော SSD သည် "classic" SATA SSD ထက်ပိုမိုမြန်ဆန်သည်ဟုထင်ရသည်မှာထင်ရှားသည်။ သို့သော် ယနေ့ကျွန်ုပ်တို့လေ့လာသိရှိထားသည့်အတိုင်း၊ တိကျသောအခြေအနေများနှင့် အချို့သောအလုပ်များတွင် ဤကိစ္စမျိုးမဖြစ်နိုင်ပါ။

IaaS ဝန်ဆောင်မှုပေးသူထံမှ ငှားရမ်းသည့်အခါ ဆာဗာအစိတ်အပိုင်းများကို သင်မည်ကဲ့သို့ စမ်းသပ်သနည်း။
မှတ်ချက်များတွင် သင့်အား ကျွန်ုပ်တို့ စောင့်မျှော်နေပါသည်။

source: www.habr.com