پرو ہوسٹر > بلاگ > انتظامیہ > میرا NVMe SSD سے سست کیوں ہے؟

میرا NVMe SSD سے سست کیوں ہے؟

میرا NVMe SSD سے سست کیوں ہے؟
اس مضمون میں ہم I/O سب سسٹم کی کچھ باریکیوں اور کارکردگی پر ان کے اثرات کو دیکھیں گے۔

کچھ ہفتے پہلے مجھے اس سوال کا سامنا کرنا پڑا کہ ایک سرور پر 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۔

ٹیسٹ Ubuntu 2255 چلانے والے Intel® Xeon® W-20.04 پر کیے جاتے ہیں۔ Sysbench 1.0.18 ڈسکوں کو جانچنے کے لیے استعمال کیا جاتا ہے۔ ڈسکوں پر ایک پارٹیشن بنایا گیا ہے، جسے ext4 کے طور پر فارمیٹ کیا گیا ہے۔ ٹیسٹ کی تیاری میں 100 جی بی فائلیں بنانا شامل ہے:

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 صفر سے بھری فائلیں تیار کرتا ہے۔ اس طرح، ٹیسٹ 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 سسٹم کال اپنے بفر سے مین سٹوریج پر ڈیٹا لکھنے کے لیے ڈرائیو کو کمانڈ بھیجتی ہے، لیکن اس بات کی تصدیق کرنے کا کوئی طریقہ نہیں ہے کہ کمانڈ صحیح طریقے سے عمل میں آیا ہے۔

چونکہ SSD بہترین نتائج دکھاتا ہے، اس لیے دو مفروضے کیے جا سکتے ہیں:

  • ڈسک کو اسی طرح کے بوجھ کے لیے ڈیزائن کیا گیا ہے۔
  • ڈسک "بلفس" کرتی ہے اور کمانڈ کو نظر انداز کرتی ہے۔

اگر آپ بجلی کے نقصان کا ٹیسٹ کراتے ہیں تو ڈرائیو کے غیر ایماندارانہ رویے کو دیکھا جا سکتا ہے۔ آپ اسے اسکرپٹ سے چیک کر سکتے ہیں۔ diskchecker.pl، وہ تھا پیدا کیا 2005 سال میں.

اس اسکرپٹ کے لیے دو جسمانی مشینوں کی ضرورت ہے - ایک "سرور" اور ایک "کلائنٹ"۔ کلائنٹ ٹیسٹ کے تحت ڈسک پر تھوڑا سا ڈیٹا لکھتا ہے، fsync کو کال کرتا ہے، اور سرور کو معلومات بھیجتا ہے کہ کیا لکھا گیا ہے۔

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

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

اسکرپٹ کو چلانے کے بعد، آپ کو "کلائنٹ" کو پاور آف کرنا چاہیے اور کئی منٹ تک پاور واپس نہ کریں۔ یہ ضروری ہے کہ اس شخص کو بجلی سے منقطع کر دیا جائے جس کا تجربہ کیا جا رہا ہے، نہ کہ صرف سخت شٹ ڈاؤن کرنا۔ کچھ وقت کے بعد، سرور کو OS میں منسلک اور لوڈ کیا جا سکتا ہے۔ OS لوڈ کرنے کے بعد آپ کو اسے دوبارہ شروع کرنے کی ضرورت ہے۔ diskchecker.pl، لیکن ایک دلیل کے ساتھ اس بات کی تصدیق.

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

چیک کے آخر میں آپ کو غلطیوں کی تعداد نظر آئے گی۔ اگر 0 ہیں، تو ڈسک نے امتحان پاس کر لیا ہے۔ ڈسک کے لئے ایک خوش قسمت اتفاق کو خارج کرنے کے لئے، تجربہ کئی بار دہرایا جا سکتا ہے.

ہمارے S4500 نے بجلی ختم ہونے پر کوئی غلطی نہیں دکھائی، یعنی یہ بہت ساری fsync کالوں کے ساتھ کام کے بوجھ کے لیے تیار ہے۔

حاصل يہ ہوا

ڈسک یا مکمل ریڈی میڈ کنفیگریشنز کا انتخاب کرتے وقت، آپ کو ان مسائل کی تفصیلات کو یاد رکھنا چاہیے جنہیں حل کرنے کی ضرورت ہے۔ پہلی نظر میں، یہ واضح لگتا ہے کہ NVMe، یعنی PCIe انٹرفیس والا SSD، "کلاسک" SATA SSD سے تیز ہے۔ تاہم، جیسا کہ آج ہم نے سیکھا ہے، مخصوص حالات میں اور بعض کاموں کے ساتھ ایسا نہیں ہو سکتا۔

IaaS فراہم کنندہ سے کرایہ پر لیتے وقت آپ سرور کے اجزاء کی جانچ کیسے کرتے ہیں؟
ہم تبصروں میں آپ کا انتظار کر رہے ہیں۔

میرا NVMe SSD سے سست کیوں ہے؟

ماخذ: www.habr.com

نیا تبصرہ شامل کریں