لماذا يكون NVMe الخاص بي أبطأ من SSD؟

لماذا يكون NVMe الخاص بي أبطأ من SSD؟
في هذه المقالة سنلقي نظرة على بعض الفروق الدقيقة في نظام الإدخال/الإخراج الفرعي وتأثيرها على الأداء.

قبل أسبوعين، واجهت سؤالًا عن سبب كون NVMe على أحد الخوادم أبطأ من SATA على خادم آخر. لقد نظرت إلى مواصفات الخادم وأدركت أن هذا سؤال صعب: كان NVMe من شريحة المستخدم، وكان SSD من شريحة الخادم.

ومن الواضح أنه ليس من العدل مقارنة المنتجات من قطاعات مختلفة في بيئات مختلفة، ولكن هذه ليست إجابة فنية كاملة. دعونا ندرس الأساسيات ونجري التجارب ونعطي إجابة على السؤال المطروح.

ما هو fsync وأين يتم استخدامه؟

لتسريع العمل مع محركات الأقراص، يتم تخزين البيانات مؤقتًا، أي تخزينها في ذاكرة متطايرة حتى تتاح فرصة مناسبة لحفظ محتويات المخزن المؤقت على محرك الأقراص. يتم تحديد معايير "الفرصة" حسب نظام التشغيل وخصائص محرك الأقراص. في حالة انقطاع التيار الكهربائي، سيتم فقدان جميع البيانات الموجودة في المخزن المؤقت.

هناك عدد من المهام التي تحتاج فيها إلى التأكد من كتابة التغييرات التي يتم إجراؤها على الملف على محرك الأقراص وليس في مخزن مؤقت متوسط. يمكن الحصول على هذا الضمان باستخدام استدعاء نظام fsync المتوافق مع POSIX. يؤدي استدعاء fsync إلى فرض الكتابة من المخزن المؤقت إلى محرك الأقراص.

دعونا نوضح تأثير المخازن المؤقتة بمثال مصطنع على شكل برنامج قصير في لغة C.

#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؟

أثناء عمليات الإدخال/الإخراج العادية، يحاول نظام التشغيل تحسين الاتصال بالأقراص، نظرًا لأن محركات الأقراص الخارجية هي الأبطأ في التسلسل الهرمي للذاكرة. ولذلك، يحاول نظام التشغيل كتابة أكبر قدر ممكن من البيانات في وصول واحد إلى محرك الأقراص.

دعونا نوضح تأثير استخدام fsync بمثال محدد. لدينا محركات أقراص SSD التالية كمحركات اختبار:

  • Intel® DC SSD S4500 سعة 480 جيجابايت، متصل عبر SATA 3.2، بسرعة 6 جيجابت/ثانية؛
  • Samsung 970 EVO Plus سعة 500 جيجابايت، متصل عبر PCIe 3.0 x4، ~31 جيجابت/ثانية.

يتم إجراء الاختبارات على Intel® Xeon® W-2255 الذي يعمل بنظام التشغيل Ubuntu 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

يتم عرض نتائج الاختبار في الجدول.

اختبار
إنتل®S4500
سامسونج 970 إيفو +

القراءة بدون 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. لماذا يعد SSD الخاص بقطاع الخادم أفضل في التعامل مع أعداد كبيرة من طلبات fsync؟

الإجابة على السؤال الأول بسيطة: يقوم sysbench بإنشاء ملفات مليئة بالأصفار. وهكذا، تم إجراء الاختبار على أكثر من 100 غيغابايت من الأصفار. نظرًا لأن البيانات موحدة جدًا ويمكن التنبؤ بها، يتم تفعيل العديد من تحسينات نظام التشغيل وتسريع التنفيذ بشكل كبير.

إذا كنت تشك في جميع نتائج 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

اختبار
إنتل®S4500
سامسونج 970 إيفو +

القراءة بدون 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

إن ميل أداء NVMe إلى الانخفاض عند استخدام fsync واضح للعيان. يمكنك الانتقال إلى الإجابة على السؤال الثاني.

التحسين أو الخداع

قلنا سابقًا أن البيانات يتم تخزينها في مخزن مؤقت، لكننا لم نحدد أي منها، لأن ذلك لم يكن مهمًا. حتى الآن لن نتعمق في تعقيدات أنظمة التشغيل وسنسلط الضوء على نوعين عامين من المخازن المؤقتة:

  • برنامج؛
  • المعدات.

يشير المخزن المؤقت للبرنامج إلى المخازن المؤقتة الموجودة في نظام التشغيل، ويشير المخزن المؤقت للأجهزة إلى الذاكرة المتطايرة لوحدة التحكم بالقرص. يرسل استدعاء نظام fsync أمرًا إلى محرك الأقراص لكتابة البيانات من المخزن المؤقت الخاص به إلى وحدة التخزين الرئيسية، ولكن ليس لديه طريقة للتحقق من تنفيذ الأمر بشكل صحيح.

وبما أن SSD يُظهر أفضل النتائج، فيمكن وضع افتراضين:

  • تم تصميم القرص لحمل مماثل؛
  • القرص "يخدع" ويتجاهل الأمر.

يمكن ملاحظة السلوك غير النزيه لمحرك الأقراص إذا قمت بإجراء اختبار فقدان الطاقة. يمكنك التحقق من ذلك باستخدام البرنامج النصي 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؟
نحن في انتظاركم في التعليقات.

لماذا يكون NVMe الخاص بي أبطأ من SSD؟

المصدر: www.habr.com

إضافة تعليق