منهنجو NVMe منهنجي SSD کان سست ڇو آهي؟

هن مقالي ۾ اسين I/O سبسسٽم جي ڪجهه nuances ۽ ڪارڪردگي تي انهن جو اثر ڏسنداسين.

ڪجهه هفتا اڳ مون کي ان سوال سان منهن ڏيڻو پيو ته ڇو هڪ سرور تي NVMe ٻئي تي SATA کان سست هو. مون سرور جي وضاحتن کي ڏٺو ۽ محسوس ڪيو ته اهو هڪ مشڪل سوال هو: NVMe صارف جي حصي مان هو، ۽ SSD سرور جي حصي مان هو.

ظاهر آهي، مختلف ماحول ۾ مختلف حصن مان پراڊڪٽس جو مقابلو ڪرڻ مناسب ناهي، پر اهو مڪمل ٽيڪنيڪل جواب ناهي. اچو ته بنيادي ڳالهين جو مطالعو ڪريون، تجربا ڪريون ۽ پڇيل سوال جو جواب ڏيون.

fsync ڇا آهي ۽ اهو ڪٿي استعمال ٿيندو آهي؟

ڊرائيوز سان ڪم کي تيز ڪرڻ لاءِ، ڊيٽا کي بفر ڪيو ويندو آهي، يعني غير مستحڪم ميموري ۾ محفوظ ڪيو ويندو آهي جيستائين ڪو آسان موقعو نه ملي ته بفر جي مواد کي ڊرائيو ۾ محفوظ ڪري سگهجي. "موقعو" جا معيار آپريٽنگ سسٽم ۽ ڊرائيو جي خاصيتن جي ذريعي طئي ڪيا ويا آهن. پاور ناڪامي جي صورت ۾، بفر ۾ سڀ ڊيٽا گم ٿي ويندا.

اهڙا ڪيترائي ڪم آهن جن ۾ توهان کي پڪ ڪرڻ جي ضرورت آهي ته فائل ۾ تبديليون ڊرائيو ڏانهن لکيل آهن ۽ وچولي بفر ۾ نه. اهو يقين حاصل ڪري سگهجي ٿو POSIX-compliant fsync سسٽم ڪال استعمال ڪندي. fsync کي ڪال ڪرڻ بفر کان ڊرائيو ڏانهن لکڻ تي مجبور ڪري ٿو.

اچو ته بفرز جي اثر کي مصنوعي مثال سان ڏيکاريون سي ۾ مختصر پروگرام جي صورت ۾.

#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;
}

تبصرا پروگرام ۾ عملن جي ترتيب کي چڱي طرح بيان ڪن ٿا. متن "زندگي جي بنيادي سوال جو جواب، ڪائنات ۽ اهو سڀ ڪجهه" آپريٽنگ سسٽم طرفان بفر ڪيو ويندو، ۽ جيڪڏهن توهان "حساب" دوران ري سيٽ بٽڻ کي دٻائي سرور کي ٻيهر شروع ڪيو، فائل خالي ٿي ويندي. اسان جي مثال ۾، متن جو نقصان ڪو مسئلو ناهي، تنهنڪري fsync جي ضرورت ناهي. ڊيٽابيس هن اميد کي حصيداري نٿا ڪن.

ڊيٽابيس پيچيده پروگرام آهن جيڪي هڪ ئي وقت ڪيترن ئي فائلن سان ڪم ڪن ٿا، تنهن ڪري هو پڪ ڪرڻ چاهين ٿا ته جيڪو ڊيٽا اهي لکندا آهن، اهو ڊرائيو تي محفوظ ڪيو ويندو، ڇاڪاڻ ته ڊيٽابيس جي اندر ڊيٽا جي مطابقت ان تي منحصر آهي. ڊيٽابيس سڀني مڪمل ٽرانزيڪشن کي رڪارڊ ڪرڻ لاءِ ٺهيل آهن ۽ ڪنهن به وقت طاقت وڃائڻ لاءِ تيار آهن. اهو رويو مسلسل وڏي مقدار ۾ fsync جي استعمال جي ضرورت آهي.

fsync جي بار بار استعمال جو اثر ڇا آهي؟

عام I/O دوران، آپريٽنگ سسٽم ڊسڪ سان رابطي کي بهتر ڪرڻ جي ڪوشش ڪندو آهي، ڇو ته خارجي ڊرائيو ميموري جي ترتيب ۾ تمام سست هوندا آهن. تنهن ڪري، آپريٽنگ سسٽم ڪوشش ڪري ٿو جيترو ممڪن حد تائين ڊيٽا کي ڊرائيو تائين هڪ رسائي ۾.

اچو ته هڪ خاص مثال سان fsync استعمال ڪرڻ جو اثر ڏيکاريون. اسان وٽ ھيٺيون SSDs ٽيسٽ ڊرائيو طور آھن:

• Intel® DC SSD S4500 480 GB، SATA 3.2 ذريعي ڳنڍيل، 6 Gbit/s؛
• Samsung 970 EVO Plus 500GB، PCIe 3.0 x4 ذريعي ڳنڍيل، ~ 31 Gbit/s.

ٽيسٽون ڪيون وينديون آهن Intel® Xeon® W-2255 تي هلندڙ Ubuntu 20.04. Sysbench 1.0.18 ڊسڪ کي جانچڻ لاء استعمال ڪيو ويندو آهي. ھڪڙو ورهاڱي ٺاھيو ويو آھي ڊسڪ تي، فارميٽ ڪيو ويو ext4. ٽيسٽ لاءِ تياري ڪرڻ ۾ 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

اهو ڏسڻ ۾ آسان آهي ته NVMe ڪلائنٽ جي حصي مان اعتماد سان اڳواڻي ۾ آهي جڏهن آپريٽنگ سسٽم پاڻ فيصلو ڪري ٿو ته ڊسڪ سان ڪيئن ڪم ڪجي، ۽ وڃائي ٿو جڏهن fsync استعمال ٿئي ٿي. هي ٻه سوال اٿاري ٿو:

1. fsync کان سواءِ ٽيسٽ ۾ پڙهڻ جي رفتار چينل جي فزيڪل بينڊوڊٿ کان ڇو وڌي ٿي؟
2. وڏي تعداد ۾ fsync درخواستن کي سنڀالڻ لاءِ سرور جو حصو SSD ڇو بهتر آهي؟

پهرين سوال جو جواب سادو آهي: sysbench zero سان ڀريل فائلون ٺاهي ٿو. اهڙيء طرح، امتحان 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 ڪارڪردگي کي خراب ڪرڻ جو رجحان واضح طور تي نظر اچي ٿو. توهان ٻئي سوال جو جواب ڏيڻ لاء اڳتي وڌائي سگهو ٿا.

اصلاح يا بلف

اڳي، اسان چيو ته ڊيٽا بفر ۾ محفوظ ڪئي وئي آهي، پر اسان اهو نه ٻڌايو آهي ته ڪهڙي هڪ، ڇو ته هي اهم نه هو. اڃا به اسان آپريٽنگ سسٽم جي پيچيدگين تي غور نه ڪنداسين ۽ ٻن عام قسمن جي بفرن کي اجاگر ڪنداسين:

• پروگرام؛
• هارڊويئر.

سافٽ ويئر بفر ان بفرز ڏانهن اشارو ڪري ٿو جيڪي آپريٽنگ سسٽم ۾ موجود آهن، ۽ هارڊويئر بفر ڊسڪ ڪنٽرولر جي غير مستحڪم ياداشت ڏانهن اشارو ڪري ٿو. fsync سسٽم ڪال ڊرائيو ڏانهن هڪ حڪم موڪلي ٿو پنهنجي بفر مان ڊيٽا کي مکيه اسٽوريج ڏانهن لکڻ لاء، پر ان جي تصديق ڪرڻ جو ڪو طريقو ناهي ته حڪم صحيح طور تي عمل ڪيو ويو آهي.

جيئن ته ايس ايس ڊي ڏيکاري ٿو بهترين نتيجا، ٻه مفروضا ٿي سگهن ٿا:

• ڊسڪ ساڳئي لوڊ لاء ٺهيل آهي؛
• ڊسڪ "bluffs" ۽ حڪم کي نظر انداز ڪري ٿو.

ڊرائيو جي بي ايماني رويي کي محسوس ڪري سگهجي ٿو جيڪڏهن توهان هڪ طاقت جي نقصان جي امتحان کي منظم ڪيو. توھان ھن کي اسڪرپٽ سان چيڪ ڪري سگھو ٿا diskchecker.pl، اهو هيو قائم ڪيل 2005 سال ۾.

ھن رسم الخط کي ٻن جسماني مشينن جي ضرورت آھي - ھڪڙو "سرور" ۽ ھڪڙو "ڪلائنٽ". ڪلائنٽ ٽيسٽ تحت ڊسڪ تي ٿورڙي ڊيٽا لکي ٿو، fsync کي ڪال ڪري ٿو، ۽ سرور ڏانهن معلومات موڪلي ٿو جيڪو لکيو ويو آهي.

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

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

اسڪرپٽ کي هلائڻ کان پوء، توهان کي "ڪلائنٽ" کي پاور بند ڪرڻ گهرجي ۽ ڪيترن ئي منٽن لاء طاقت واپس نه ڏيو. اهو ضروري آهي ته جيڪو شخص بجليء کان آزمائي رهيو آهي، ان کي ختم ڪرڻ ضروري آهي، ۽ نه صرف هڪ سخت بندش انجام ڏيو. ڪجھ وقت کان پوء، سرور ڳنڍي سگھجي ٿو ۽ او ايس ۾ لوڊ ٿي سگھي ٿو. او ايس کي لوڊ ڪرڻ کان پوء توهان کي ٻيهر شروع ڪرڻ جي ضرورت آهي diskchecker.pl، پر هڪ دليل سان تصديق ڪريو.

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

چڪاس جي آخر ۾ توھان ڏسندا غلطين جو تعداد. جيڪڏهن 0 آهن، ته ڊسڪ ٽيسٽ پاس ڪيو آهي. ڊسڪ لاء هڪ خوش قسمت اتفاق کي خارج ڪرڻ لاء، تجربو ڪيترائي ڀيرا بار بار ڪري سگهجي ٿو.

اسان جي S4500 ۾ ڪابه غلطي نه ڏيکاري وئي جڏهن پاور گم ٿي وئي، مطلب ته اهو تمام گهڻي fsync ڪالن سان ڪم لوڊ ڪرڻ لاءِ تيار آهي.

ٿڪل

جڏهن ڊسڪ يا مڪمل تيار ڪيل ترتيبن کي چونڊيو، توهان کي انهن مسئلن جي وضاحتن کي ياد رکڻ گهرجي جنهن کي حل ڪرڻ جي ضرورت آهي. پهرين نظر ۾، اهو ظاهر ٿئي ٿو ته NVMe، اهو آهي، هڪ SSD هڪ PCIe انٽرفيس سان، "ڪلاسڪ" SATA SSD کان تيز آهي. تنهن هوندي، جيئن اسان اڄ سکيو آهي، خاص حالتن ۾ ۽ ڪجهه خاص ڪمن سان اهو معاملو نه ٿي سگهي.

IaaS فراهم ڪندڙ کان ڪرائي تي ڏيڻ دوران توهان سرور جي اجزاء کي ڪيئن جانچيندا آهيو؟
اسان تبصرن ۾ توهان جي انتظار ۾ آهيون.

جو ذريعو: www.habr.com