Zfs: تجزئة ملف الكتابة على مراحل على أنظمة متعددة النواة

تم إنشاؤها على ١ فبراير ٢٠١٨ · 4تعليقات · مصدر: openzfs/zfs

معلومات النظام

صِف المشكلة التي تراقبها

بعد كتابة أداة لعرض تجزئة الملف كما يراها zdb ، لاحظت أنه حتى الملف الذي تم إنشاؤه حديثًا بواسطة cp ، على تجمع به مساحة حرة وفيرة ، سيكون به 2-3 أجزاء لكل ميجابايت ؛ لملف 300 ميغا بايت ، أي 700-900 جزء.

بعد تعطيل 7 من نوى النظام الثمانية من خلال /sys/devices/cpu/cpu[1-7]/online وإعادة الكتابة ، رأيت 8 إلى 10 أجزاء فقط. أدت إعادة تمكين النوى إلى جعل الكتابات الجديدة مجزأة كما كانت دائمًا.

تتجلى الشظايا كما يكتب متداخلة ؛ يتم إعادة ترتيب الأقسام الفردية ، ولكن لا يتم كتابتها أبدًا بعيدًا عن المكان الذي يجب أن تكون فيه ، أي بدلاً من ترتيب "ABCDEFGHI" ، قد أرى بدلاً من ذلك "BACEDFIGH".

تم تأكيد ذلك أيضًا في تجمع أحادي القرص تم إنشاؤه حديثًا.

صف كيفية إعادة إنتاج المشكلة

تكرار الإجراء الخاص بي من أعلى. لفحص الملفات الناتجة ، يمكنك استخدام الأداة printzfrag :

printzblock() {
  sudo zdb -ddddd $(df --output=source --type=zfs "$1" | tail -n +2) $(stat -c %i "$1")
}

printzfrag() {
  printzblock "$@" \
    | grep ' L0' \
    | awk '{print $3}' \
    | gawk -F: \
      'BEGIN {
        pos=0
        segments=0
      } {
         segstart = strtonum("0x" $2)
         size = strtonum("0x" $3)
         if (pos != segstart) {
           segments += 1
           print old, " -- ", $0, " -- ", pos - segstart
         }
         pos = segstart + size
         old = $0
      } END {
         print segments
      }'
}

والذي سينتج شيئًا مشابهًا لـ http://ix.io/F27.

يُظهر العمود الأخير إزاحة كل جزء من موقعه "المتوقع" ، مما يُظهر نمطًا يسهل التعرف عليه من الكتابات المتداخلة.

الأداة غير مخصصة ولن تعمل بشكل جيد في تجمعات vdev المتعددة.

Stale Performance

مصدر

Baughn

التعليق الأكثر فائدة

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

behlendorf في ١ فبراير ٢٠١٨

👍3

ال 4 كومينتر

behlendorf في ١ فبراير ٢٠١٨

👍3

من الناحية العملية ، تكون معظم الكتل كبيرة ويتم جلبها مسبقًا بالتسلسل ، وبالتالي يكون تأثير ذلك في حده الأدنى عادةً.

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

Baughn في ٤ فبراير ٢٠١٨

👍1

يبدو أن تقليل zfs_sync_taskq_batch_pct يجعل TxG يلتزم "الخطي" بشكل أكبر ويعزز المزيد من تجميع الكتابة. أظن أن هذا هو السبب. النسبة الافتراضية 75٪ كبيرة جدًا لمعظم الأنظمة التي تحتوي على الكثير من المعالجات. انتهى بي الأمر باستخدام في مكان ما بين 2-5 سلاسل لها في معظم الحالات.

كجزء من الضبط ، أجد أن ما هو مفيد هو فتح خانق ZIO ، والحصول على سلاسل كتابة غير متزامنة مناسبة ، والعثور على النقطة التي يمكن عندها zfs_sync_taskq_batch_pct فقط إنشاء بيانات بسرعة كافية للاستفادة الكاملة من الأقراص. توفر هذه النقطة أكثر احتمالية لدمج الكتابة وحدود معدل قراءات TxG sync RMW. بعد ذلك ، اطلب الخيوط ، ثم اضبط دواسة الوقود ZIO بشكل أكثر مرونة مما يجب أن تكون عليه للحفاظ على النتائج السابقة. يمنحنا هذا عمليات كتابة متسلسلة كافية للدفق بسهولة لحظر الأجهزة عبر شبكة WAN ، ولم أر مطلقًا التزام TxG بهذه النظافة.

janetcampbell في ٦ أبريل ٢٠١٩

تم وضع علامة على هذه المشكلة تلقائيًا على أنها "قديمة" لأنه لم يكن بها أي نشاط منذ فترة. سيتم إغلاقه في غضون 90 يومًا إذا لم يحدث أي نشاط آخر. شكرا لمساهماتكم.