تم إعداد ترجمة المقال عشية بدء الدورة .
بشكل دوري ، هنا وهناك ، تظهر أسئلة حول توصيات Gluster بخصوص ضبط النواة وما إذا كانت هناك حاجة لذلك.
نادرا ما تنشأ مثل هذه الحاجة. في معظم أحمال العمل ، تعمل النواة بشكل جيد جدًا. على الرغم من وجود جانب سلبي. من الناحية التاريخية ، كانت نواة Linux على استعداد لاستهلاك قدر كبير من الذاكرة إذا أتيحت لها الفرصة ، بما في ذلك التخزين المؤقت باعتباره الطريقة الرئيسية لتحسين الأداء.
في معظم الحالات ، يعمل هذا بشكل جيد ، ولكن تحت الحمل الثقيل يمكن أن يؤدي إلى مشاكل.
لدينا الكثير من الخبرة في أنظمة الذاكرة المكثفة مثل CAD و EDA وما شابه ، والتي بدأت في التباطؤ تحت الحمل الثقيل. وأحيانًا واجهنا مشاكل في Gluster. بعد المراقبة الدقيقة لاستخدام الذاكرة وزمن انتقال القرص لعدة أيام ، حصلنا على حمل زائد ، و iowait ضخم ، وأخطاء kernel (kernel oops) ، وتجمد ، وما إلى ذلك.
هذه المقالة هي نتيجة العديد من تجارب الضبط التي أجريت في مواقف مختلفة. بفضل هذه المعلمات ، لم تتحسن الاستجابة الإجمالية فحسب ، بل استقرت الكتلة أيضًا بشكل كبير.
عندما يتعلق الأمر بضبط الذاكرة ، فإن أول ما يجب النظر إليه هو النظام الفرعي للذاكرة الافتراضية (VM ، الذاكرة الافتراضية) ، والذي يحتوي على عدد كبير من الخيارات التي يمكن أن تربكك.
vm.swappiness
المعلمة vm.swappiness يحدد مقدار استخدام kernel للمبادلة (swap ، paging) مقارنةً بذاكرة الوصول العشوائي (RAM). يتم تعريفه أيضًا في الكود المصدري على أنه "الميل إلى سرقة الذاكرة المعينة". تعني المبادلة العالية أن النواة ستكون أكثر ميلًا لمبادلة الصفحات المعينة. تعني المبادلة المنخفضة العكس: ستخرج النواة أقل من الذاكرة. بمعنى آخر ، كلما ارتفعت القيمة vm.swappiness، كلما زاد استخدام النظام للمبادلة.
يعد الاستخدام الكبير للمبادلة أمرًا غير مرغوب فيه ، حيث يتم تحميل كتل ضخمة من البيانات وتفريغها في ذاكرة الوصول العشوائي. كثير من الناس يجادلون بأن قيمة المبادلة يجب أن تكون كبيرة ، ولكن من واقع خبرتي ، فإن ضبطها على "0" يؤدي إلى أداء أفضل.
يمكنك قراءة المزيد هنا -
ولكن ، مرة أخرى ، يجب تطبيق هذه الإعدادات بعناية وفقط بعد اختبار تطبيق معين. بالنسبة لتطبيقات التدفق عالية التحميل ، يجب تعيين هذا المعامل على "0". عند التغيير إلى "0" ، تتحسن استجابة النظام.
vm.vfs_cache_pressure
يتحكم هذا الإعداد في الذاكرة التي تستهلكها النواة للتخزين المؤقت للدليل وكائنات inode (dentry و inode).
مع القيمة الافتراضية 100 ، سيحاول kernel تحرير مخازن dentry و inode على أساس "عادل" إلى pagecache و swapcache. يؤدي تقليل vfs_cache_pressure إلى احتفاظ النواة بمخازن dentry و inode. عندما تكون القيمة "0" ، لن يقوم kernel مطلقًا بمسح السنترة وذاكرة التخزين المؤقت inode بسبب ضغط الذاكرة ، وهذا يمكن أن يؤدي بسهولة إلى خطأ نفاد الذاكرة. تؤدي زيادة vfs_cache_pressure إلى ما يزيد عن 100 إلى قيام النواة بإعطاء الأولوية لطب الأسنان وتنظيف inode.
عند استخدام GlusterFS ، يمكن للعديد من المستخدمين الذين لديهم كميات كبيرة من البيانات والعديد من الملفات الصغيرة بسهولة استخدام قدر كبير من ذاكرة الوصول العشوائي على الخادم بسبب التخزين المؤقت inode / dentry ، مما قد يؤدي إلى تدهور الأداء حيث يتعين على kernel معالجة هياكل البيانات على النظام مع ذاكرة 40 جيجا بايت. ساعد تعيين هذه القيمة فوق 100 العديد من المستخدمين على تحقيق تخزين مؤقت أكثر عدلاً واستجابة kernel محسّنة.
vm.dirty_background_ratio و vm.dirty_ratio
المعلمة الأولى (vm.dirty_background_ratio) يحدد النسبة المئوية للذاكرة ذات الصفحات المتسخة ، وبعد الوصول إلى ذلك من الضروري البدء في مسح الصفحات المتسخة في الخلفية على القرص. حتى يتم الوصول إلى هذه النسبة المئوية ، لا يتم مسح أي صفحات على القرص. وعند بدء إعادة التعيين ، يتم تشغيلها في الخلفية دون مقاطعة العمليات الجارية.
المعلمة الثانية (vm.dirty_ratio) يحدد النسبة المئوية للذاكرة التي يمكن أن تشغلها الصفحات المتسخة قبل أن يبدأ الفلاش الإجباري. بمجرد الوصول إلى هذه العتبة ، تصبح جميع العمليات متزامنة (محظورة) ولا يُسمح لها بالاستمرار حتى اكتمال الإدخال / الإخراج الذي طلبوه بالفعل وتكون البيانات على القرص. مع الإدخال / الإخراج الثقيل ، يتسبب هذا في مشكلة لأنه لا يوجد تخزين مؤقت للبيانات ويتم حظر جميع العمليات التي تقوم بإدخال / إخراج في انتظار الإدخال / الإخراج. هذا يؤدي إلى عدد كبير من العمليات المعلقة ، والحمل العالي ، وعدم استقرار النظام وضعف الأداء.
يؤدي تقليل هذه الإعدادات إلى مسح البيانات إلى القرص بشكل متكرر وعدم تخزينها في ذاكرة الوصول العشوائي. يمكن أن يساعد هذا الأنظمة ذات الذاكرة الثقيلة التي لا بأس بها في مسح ذاكرة التخزين المؤقت للصفحة من 45 إلى 90 جيجابايت على القرص ، مما يؤدي إلى زمن انتقال كبير للتطبيقات الأمامية ، مما يقلل من الاستجابة والتفاعلية بشكل عام.
"1"> / proc / sys / vm / pagecache
ذاكرة التخزين المؤقت للصفحة هي ذاكرة تخزين مؤقت تخزن بيانات الملفات والبرامج القابلة للتنفيذ ، أي أنها صفحات تحتوي على المحتويات الفعلية للملفات أو الأجهزة المحظورة. يتم استخدام ذاكرة التخزين المؤقت هذه لتقليل عدد قراءات القرص. تعني القيمة "1" أنه يتم استخدام 1٪ من ذاكرة الوصول العشوائي لذاكرة التخزين المؤقت وستكون هناك عمليات قراءة من القرص أكثر من ذاكرة الوصول العشوائي. ليس من الضروري تغيير هذا الإعداد ، ولكن إذا كنت تشعر بجنون العظمة بشأن التحكم في ذاكرة التخزين المؤقت للصفحة ، فيمكنك استخدامها.
"الموعد النهائي"> / sys / block / sdc / queue / Scheduler
جدولة الإدخال / الإخراج هي أحد مكونات Linux kernel التي تتعامل مع قوائم انتظار القراءة والكتابة. من الناحية النظرية ، من الأفضل استخدام "noop" لوحدة تحكم RAID ذكية ، لأن Linux لا يعرف شيئًا عن الهندسة الفيزيائية للقرص ، لذلك من الأفضل السماح لوحدة التحكم ، التي تعرف هندسة القرص جيدًا ، بمعالجة الطلب بأسرع ما يمكن ممكن. ولكن يبدو أن "الموعد النهائي" يحسن الأداء. يمكنك قراءة المزيد حول الجدولة في وثائق التعليمات البرمجية المصدر لـ Linux kernel: linux/Documentation/block/*osched.txt. كما أنني رأيت زيادة في معدل نقل القراءة أثناء العمليات المختلطة (يكتب العديد).
"256"> / sys / block / sdc / queue / nr_requests
عدد طلبات الإدخال / الإخراج في المخزن المؤقت قبل أن يتم تمريرها إلى المجدول. يكون حجم قائمة الانتظار الداخلية لبعض وحدات التحكم (queue_depth) أكبر من طلبات جدولة الإدخال / الإخراج nr ، وبالتالي فإن برنامج جدولة الإدخال / الإخراج لديه فرصة ضئيلة لتحديد أولويات الطلبات ودمجها بشكل صحيح. بالنسبة إلى المواعيد النهائية وجدولة CFQ ، من الأفضل أن تكون nr_requests ضعف قائمة الانتظار الداخلية لوحدة التحكم. يساعد دمج الطلبات وإعادة ترتيبها المجدول على أن يكون أكثر استجابة في ظل الحمل الثقيل.
صدى "16"> / proc / sys / vm / page-cluster
تتحكم معلمة مجموعة الصفحات في عدد الصفحات المكتوبة إلى المبادلة في وقت واحد. في المثال أعلاه ، تم تعيين القيمة على "16" وفقًا لحجم شريط RAID البالغ 64 كيلوبايت. هذا غير منطقي مع swappiness = 0 ، ولكن إذا قمت بتعيين Swappiness على 10 أو 20 ، فإن استخدام هذه القيمة سيساعدك عندما يكون حجم شريط RAID 64 كيلو.
blockdev - سيترا 4096 / ديف /<اسم المطور> (-sdb أو hdc أو dev_mapper)
غالبًا ما تؤدي إعدادات جهاز الحظر الافتراضية للعديد من وحدات تحكم RAID إلى أداء سيئ. تؤدي إضافة الخيار أعلاه إلى إعداد القراءة المسبقة لقطاعات 4096 * 512 بايت. على الأقل ، بالنسبة لعمليات التدفق ، يتم زيادة السرعة عن طريق ملء ذاكرة التخزين المؤقت على القرص بالقراءة المسبقة خلال الفترة التي تستخدمها النواة لإعداد الإدخال / الإخراج. يمكن أن تحتوي ذاكرة التخزين المؤقت على البيانات التي سيتم طلبها في القراءة التالية. يمكن أن يؤدي الجلب المسبق كثيرًا إلى قتل الإدخال / الإخراج العشوائي للملفات الكبيرة إذا كان يستخدم وقت القرص المفيد المحتمل أو يقوم بتحميل البيانات خارج ذاكرة التخزين المؤقت.
فيما يلي بعض التوصيات الإضافية على مستوى نظام الملفات. لكن لم يتم اختبارهم بعد. تأكد من أن نظام الملفات يعرف حجم الشريط وعدد الأقراص في المصفوفة. على سبيل المثال ، هذه مجموعة raid5 شريطية 64 كيلو بايت من ستة أقراص (في الواقع خمسة أقراص ، لأنه يتم استخدام قرص واحد للتكافؤ). تستند هذه التوصيات إلى افتراضات نظرية وتم تجميعها من مدونات / مقالات مختلفة بواسطة خبراء RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))بالنسبة للملفات الكبيرة ، ضع في اعتبارك زيادة أحجام الشريط المذكورة أعلاه.
تحذير! كل ما هو موصوف أعلاه شخصي للغاية لبعض أنواع التطبيقات. لا تضمن هذه المقالة أي تحسينات بدون اختبار المستخدم مسبقًا للتطبيقات ذات الصلة. يجب استخدامه فقط إذا كان من الضروري تحسين الاستجابة الشاملة للنظام ، أو إذا كان يحل المشاكل الحالية.
مواد إضافية:
اقرأ أكثر
المصدر: www.habr.com