سرعة التخزين مناسبة ل الخ؟ دعنا نسأل fio

قصة قصيرة عن fio و etcd

أداء الكتلة إلخ يعتمد إلى حد كبير على أداء التخزين الخاص به. إلخ ، يصدر بعض المقاييس إلى محب العمللتوفير معلومات أداء التخزين المطلوبة. على سبيل المثال ، مقياس wal_fsync_duration_seconds. وثائق ل الخ: لكي يتم اعتبار التخزين سريعًا بدرجة كافية ، يجب أن تكون النسبة المئوية 99 من هذا المقياس أقل من 10 مللي ثانية. إذا كنت تخطط لتشغيل مجموعة etcd على أجهزة Linux وترغب في تقييم ما إذا كانت سعة التخزين لديك سريعة بما يكفي (مثل SSD) ، فيمكنك استخدام خيط هي أداة شائعة لاختبار عمليات الإدخال / الإخراج. قم بتشغيل الأمر التالي ، حيث test-data هو الدليل الموجود أسفل نقطة تحميل التخزين:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

ما عليك سوى إلقاء نظرة على النتائج والتحقق من النسبة المئوية 99 من المدة com.fdatasync أقل من 10 مللي ثانية. إذا كان الأمر كذلك ، فلديك سعة تخزينية سريعة بشكل معقول. فيما يلي مثال على النتائج:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

الملاحظات

• لقد قمنا بتخصيص خياري - size و --bs للسيناريو الخاص بنا. للحصول على نتيجة مفيدة من fio ، قدم القيم الخاصة بك. من أين تحصل عليها؟ يقرأ كيف تعلمنا تكوين fio.
• أثناء الاختبار ، تأتي كل أحمال الإدخال / الإخراج من fio. في سيناريو الحياة الواقعية ، من المحتمل أن تكون هناك طلبات كتابة أخرى تأتي إلى التخزين إلى جانب تلك المتعلقة بـ wal_fsync_duration_seconds. سيؤدي الحمل الإضافي إلى زيادة قيمة wal_fsync_duration_seconds. لذلك إذا كانت النسبة المئوية 99 قريبة من 10 مللي ثانية ، فإن سرعة التخزين لديك تنفد.
• خذ النسخة خيط لا أقل من 3.5 (لا تعرض القيم السابقة النسب المئوية لمدة fdatasync).
• أعلاه مجرد مقتطف من النتائج من fio.

قصة طويلة حول fio و etcd

ما هو WAL في الخ

عادة ما تستخدم قواعد البيانات سجل الكتابة المسبقة؛ إلخ يستخدمه أيضًا. لن نناقش سجل الكتابة المسبقة (WAL) بالتفصيل هنا. يكفي لنا أن نعرف أن كل عضو من أعضاء الكتلة etcd يحتفظ به في تخزين دائم. يكتب etcd كل عملية ذات قيمة مفتاح (مثل تحديث) إلى WAL قبل تطبيقه على المتجر. إذا تعطل أحد أعضاء التخزين وأعاد تشغيله بين اللقطات ، فيمكنه استعادة المعاملات محليًا منذ اللقطة الأخيرة بواسطة محتوى WAL.

عندما يضيف العميل مفتاحًا إلى مخزن قيمة المفتاح أو يقوم بتحديث قيمة مفتاح موجود ، فإن etcd يسجل العملية في WAL ، وهو ملف عادي في التخزين الدائم. إلخ ، يجب أن تكون متأكدًا تمامًا من أن إدخال WAL قد حدث بالفعل قبل متابعة المعالجة. في نظام Linux ، لا تكفي مكالمة نظام واحدة لهذا الغرض. اكتب، نظرًا لأن الكتابة الفعلية للتخزين الفعلي قد تتأخر. على سبيل المثال ، قد يقوم Linux بتخزين إدخال WAL في ذاكرة تخزين مؤقت في ذاكرة kernel (مثل ذاكرة التخزين المؤقت للصفحة) لبعض الوقت. ولكي تتم كتابة البيانات بدقة في التخزين الدائم ، يلزم استدعاء نظام fdatasync بعد الكتابة ، وما إلى ذلك يستخدمها فقط (كما ترى في نتيجة العمل عنيد، حيث 8 هو واصف ملف WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

لسوء الحظ ، لا تتم الكتابة إلى التخزين الدائم على الفور. إذا كانت مكالمة fdatasync بطيئة ، فسوف يتأثر أداء نظام etcd. وثائق ل الخأن التخزين يعتبر سريعًا بدرجة كافية إذا استغرقت مكالمات fdatasync ، في النسبة المئوية 99 ، أقل من 10 مللي ثانية للكتابة إلى ملف WAL. هناك مقاييس أخرى مفيدة للتخزين ، ولكن في هذا المنشور نتحدث فقط عن هذا المقياس.

تقدير التخزين باستخدام fio

إذا كنت بحاجة إلى تقييم ما إذا كان التخزين الخاص بك مناسبًا وما إلى ذلك ، فاستخدم fio ، وهي أداة اختبار تحميل I / O شائعة جدًا. يجب أن نتذكر أن عمليات القرص يمكن أن تكون مختلفة جدًا: متزامنة وغير متزامنة ، العديد من فئات استدعاءات النظام ، إلخ. ونتيجة لذلك ، من الصعب جدًا استخدام fio. يحتوي على العديد من المعلمات ، وتنتج مجموعات مختلفة من قيمها أحمال عمل إدخال / إخراج مختلفة جدًا. للحصول على أرقام مناسبة لـ etcd ، يجب عليك التأكد من أن حمل كتابة الاختبار من fio أقرب ما يمكن إلى الحمل الفعلي من etcd عند كتابة ملفات WAL.

لذلك ، يجب على fio ، كحد أدنى ، إنشاء حمل من سلسلة من عمليات الكتابة المتسلسلة إلى الملف ، وستتكون كل عملية كتابة من استدعاء نظام اكتبمتبوعًا باستدعاء نظام fdatasync. تتطلب عمليات الكتابة المتسلسلة إلى fio الخيار --rw = write. لكي يستخدم fio استدعاء نظام الكتابة عند الكتابة ، بدلاً من بورايت، يجب عليك تحديد المعلمة --ioengine = sync. أخيرًا ، لاستدعاء fdatasync بعد كل عملية كتابة ، تحتاج إلى إضافة المعلمة --fdatasync = 1. الخياران الآخران في هذا المثال (- size و -bs) خاصان بالنص. في القسم التالي ، سنوضح لك كيفية إعدادها.

لماذا fio وكيف تعلمنا إعداده

في هذا المنشور ، نصف حالة حقيقية. لدينا كتلة Kubernetes الإصدار 1.13 الذي قمنا بمراقبته باستخدام بروميثيوس. تم استضافة etcd v3.2.24 على SSD. أظهرت مقاييس Etcd أن زمن انتقال fdatasync مرتفع جدًا ، حتى عندما كانت الكتلة لا تفعل شيئًا. كانت المقاييس غريبة ولم نكن نعرف حقًا ما تعنيه. تتكون المجموعة من أجهزة افتراضية ، وكان من الضروري فهم المشكلة: في محركات أقراص الحالة الصلبة المادية أو في طبقة المحاكاة الافتراضية. بالإضافة إلى ذلك ، غالبًا ما أجرينا تغييرات على تكوين الأجهزة والبرامج ، وكنا بحاجة إلى طريقة لتقييم نتائجها. يمكننا تشغيل etcd في كل تكوين وإلقاء نظرة على مقاييس بروميثيوس ، لكن هذا يمثل الكثير من المتاعب. كنا نبحث عن طريقة بسيطة إلى حد ما لتقييم تكوين معين. أردنا التحقق مما إذا كنا نفهم مقاييس بروميثيوس من الخ بشكل صحيح.

لكن لهذا ، كان لا بد من حل مشكلتين. أولاً ، كيف يبدو تحميل الإدخال / الإخراج الذي ينشئه وما إلى ذلك عند الكتابة إلى WAL؟ ما هي مكالمات النظام المستخدمة؟ ما هو حجم السجلات؟ ثانيًا ، إذا أجبنا على هذه الأسئلة ، كيف يمكننا إعادة إنتاج عبء عمل مماثل باستخدام fio؟ لا تنس أن fio هي أداة مرنة للغاية مع العديد من الخيارات. لقد حللنا كلتا المشكلتين بنهج واحد - باستخدام الأوامر lsof и عنيد. يسرد lsof جميع واصفات الملفات التي تستخدمها العملية والملفات المرتبطة بها. وباستخدام الاستقامة ، يمكنك فحص عملية قيد التشغيل بالفعل ، أو بدء عملية وفحصها. strace يطبع جميع استدعاءات النظام من العملية قيد الفحص (والعمليات التابعة لها). هذا الأخير مهم للغاية ، حيث أن إلخ تتخذ نهجًا مشابهًا.

استخدمنا أولاً strace لاستكشاف خادم etcd لـ Kubernetes عندما لم يكن هناك حمل على المجموعة. لقد رأينا أن جميع سجلات WAL تقريبًا كانت بنفس الحجم تقريبًا: 2200-2400 بايت. لذلك ، في الأمر في بداية المنشور ، حددنا المعامل -bs = 2300 (يعني bs الحجم بالبايت لكل إدخال fio). لاحظ أن حجم الإدخال etcd يعتمد على الإصدار وما إلى ذلك ، والتوزيع ، وقيم المعلمات ، وما إلى ذلك ، ويؤثر على مدة fdatasync. إذا كان لديك سيناريو مشابه ، فقم بفحص العمليات وما إلى ذلك لديك بتركيز لمعرفة الأرقام الدقيقة.

بعد ذلك ، للحصول على فكرة جيدة عما يفعله نظام الملفات etcd ، بدأناه بخيارات strace وخيارات -ffttT. لذلك حاولنا فحص العمليات الفرعية وتسجيل مخرجات كل منها في ملف منفصل ، وكذلك الحصول على تقارير مفصلة حول بدء ومدة كل مكالمة نظام. استخدمنا lsof لتأكيد تحليلنا لإخراج strace ومعرفة واصف الملف الذي تم استخدامه لأي غرض. لذلك بمساعدة الدعامة ، تم الحصول على النتائج الموضحة أعلاه. أكدت إحصائيات وقت المزامنة أن wal_fsync_duration_seconds من etcd يتوافق مع مكالمات fdatasync مع واصفات ملفات WAL.

لقد راجعنا وثائق fio واخترنا خيارات للبرنامج النصي الخاص بنا بحيث يُنشئ fio حملًا مشابهًا لـ etcd. قمنا أيضًا بفحص مكالمات النظام ومدتها عن طريق تشغيل fio من strace ، على غرار etcd.

لقد اخترنا بعناية قيمة المعلمة --size لتمثيل تحميل الإدخال / الإخراج بالكامل من fio. في حالتنا ، هذا هو العدد الإجمالي للبايتات المكتوبة في وحدة التخزين. اتضح أنه يتناسب طرديًا مع عدد استدعاءات نظام الكتابة (و fdatasync). لقيمة معينة من bs ، عدد مكالمات fdatasync = size / bs. نظرًا لأننا كنا مهتمين بالنسب المئوية ، كان علينا الحصول على عينات كافية للتأكد ، وقد حسبنا أن 10 ^ 4 ستكون كافية بالنسبة لنا (أي 22 ميبي بايت). إذا كان - الحجم أصغر ، فقد تحدث القيم المتطرفة (على سبيل المثال ، تستغرق العديد من مكالمات fdatasync وقتًا أطول من المعتاد وتؤثر على النسبة المئوية 99).

جربه بنفسك

لقد أوضحنا لك كيفية استخدام fio ومعرفة ما إذا كان التخزين به سرعة كافية للأداء العالي وما إلى ذلك. يمكنك الآن تجربتها بنفسك باستخدام ، على سبيل المثال ، الأجهزة الافتراضية مع تخزين SSD آي بي إم الغيمة.

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