من وقت لآخر ، تظهر أسئلة هنا وهناك حول توصيات Gluster بخصوص ضبط النواة وما إذا كانت هناك حاجة لذلك.
هذه الحاجة نادرة. تعمل النواة بشكل جيد للغاية في معظم أحمال العمل. على الرغم من وجود جانب سلبي. من الناحية التاريخية ، تستهلك نواة Linux بشغف الكثير من الذاكرة إذا أتيحت لها الفرصة ، بما في ذلك التخزين المؤقت باعتباره الطريقة الرئيسية لتحسين الأداء.
يعمل هذا بشكل جيد في معظم الأوقات ، ولكن تحت الحمل الثقيل يمكن أن يؤدي إلى مشاكل.
لدينا الكثير من الخبرة في الأنظمة التي تستهلك قدرًا كبيرًا من الذاكرة ، مثل CAD و EDA وما شابه ، والتي بدأت في التباطؤ في ظل الحمل العالي. وأحيانًا واجهنا مشاكل مع Gluster. بعد المراقبة الدقيقة للذاكرة المستخدمة وزمن انتقال القرص لأكثر من يوم واحد ، حصلنا على حمل زائد ، و iowait ضخم ، وأخطاء kernel (kernel oops) ، وتجمد ، وما إلى ذلك.
هذه المقالة هي نتيجة العديد من تجارب الضبط التي أجريت في مواقف مختلفة. لم تعمل هذه المعايير على تحسين الاستجابة الإجمالية فحسب ، بل أدت أيضًا إلى استقرار أداء الكتلة بشكل كبير.
عندما يتعلق الأمر بضبط الذاكرة ، فإن أول ما يجب النظر إليه هو النظام الفرعي للذاكرة الافتراضية (VM) ، والذي يحتوي على عدد كبير من الخيارات التي يمكن أن تربكك.
vm.swappiness
vm.swappinessتحدد
هذه المعلمة مقدار استخدام kernel للمبادلة (swap) مقارنةً بذاكرة الوصول العشوائي. في التعليمات البرمجية المصدر ، يتم تعريفها أيضًا على أنها "الميل إلى سرقة الذاكرة المعينة" (الميل إلى سرقة الذاكرة المعينة). تعني قيمة المبادلة العالية أن النواة ستكون أكثر عرضة لتفريغ الصفحات المقدمة. تعني قيمة المبادلة المنخفضة العكس: ستتبادل النواة صفحات أقل من الذاكرة. بمعنى آخر ، كلما ارتفعت القيمة vm.swappiness، زاد تبديل النظام.
الاستخدام الكبير للتبديل غير مرغوب فيه ، حيث يتم تحميل كتل ضخمة من البيانات وتفريغها في ذاكرة الوصول العشوائي. قد يجادل الكثيرون بأن قيمة المبادلة يجب أن تكون عالية ، ولكن من واقع خبرتي ، فإن تعيينها على "0" سيزيد من الأداء.
يمكنك قراءة المزيد من التفاصيل هنا -lwn.net/Articles/100978
ولكن ، مرة أخرى ، يجب تطبيق هذه الإعدادات بحذر وبعد اختبار تطبيق معين فقط. بالنسبة لتطبيقات التدفق عالية التحميل ، يجب تعيين هذا المعامل على "0". يؤدي التغيير إلى "0" إلى تحسين استجابة النظام.
vm.vfs_cache_pressure
تتحكم هذه المعلمة في الذاكرة التي تستهلكها النواة للتخزين المؤقت لكائنات الدليل و inodes (dentry و inode).
باستخدام الإعداد الافتراضي 100 ، ستحاول kernel تحرير مخابئ dentry و inode بإنصاف إلى pagecache و swapcache. يؤدي تقليل vfs_cache_pressure إلى احتفاظ kernel بمخازن dentry و inode. عندما تكون القيمة 0 ، فإن kernel لن يمسح مخابئ dentry و 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/Documentation/block/*osched.txt. ورأيت أيضًا زيادة في معدل نقل القراءة أثناء العمليات المختلطة (يكتب العديد).
"256"> / sys / block / sdc / queue / nr_requests
عدد طلبات الإدخال / الإخراج في المخزن المؤقت قبل إرسالها إلى المجدول. تحتوي بعض وحدات التحكم على حجم قائمة انتظار داخلي (queue_depth) أكبر من nr_quests الخاصة بجدول I / O ، وبالتالي فإن برنامج جدولة الإدخال / الإخراج لديه فرصة ضئيلة في تحديد أولويات الطلبات ودمجها بشكل صحيح. بالنسبة إلى جدولة الموعد النهائي وجداول CFQ ، فمن الأفضل عندما تكون nr_requests ضعف قائمة الانتظار الداخلية لوحدة التحكم. يساعد دمج الاستعلامات وإعادة ترتيبها المخطط على أن يكون أكثر استجابة في ظل الحمل الثقيل.
صدى "16"> / proc / sys / vm / page-cluster
تتحكم معلمة مجموعة الصفحات في عدد الصفحات المكتوبة إلى المبادلة في وقت واحد. في المثال أعلاه ، تم تعيين القيمة على "16" لتتناسب مع حجم شريط 64 كيلو بايت من RAID. لا معنى لذلك مع swappiness = 0 ، ولكن إذا قمت بتعيين Swappiness على 10 أو 20 ، فإن استخدام هذه القيمة سيساعدك عندما يكون حجم شريط RAID 64 كيلو بايت.
blockdev --setra 4096 / dev / <devname >(-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))بالنسبة للملفات الكبيرة ، ضع في اعتبارك زيادة أحجام الشريط أعلاه.
انتباه! كل ما هو موصوف أعلاه شخصي للغاية لبعض أنواع التطبيقات. لا تضمن هذه المقالة أي تحسين بدون اختبار مسبق للمستخدم للتطبيقات المعنية. يجب استخدامه فقط إذا كان من الضروري تحسين الاستجابة الشاملة للنظام ، أو إذا كان يحل المشاكل الحالية.
مواد إضافية:
- dom.as/2008/02/05/linux-io-schedulers
- www.nextre.it/oracledocs/oraclemyths.html
- lkml.org/lkml/2006/11/15/40
- misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html
اقرأ أكثر