أفضل ممارسات ذاكرة التخزين المؤقت لنظام ملفات Linux لملفات Azure NetApp
تساعدك هذه المقالة على فهم أفضل ممارسات ذاكرة التخزين المؤقت لنظام الملفات لملفات Azure NetApp.
ضبط ذاكرة التخزين المؤقت لنظام الملفات
تحتاج إلى فهم العوامل التالية حول ضبط ذاكرة التخزين المؤقت لنظام الملفات:
- يؤدي مسح مخزن مؤقت قذر إلى ترك البيانات في حالة نظيفة قابلة للاستخدام في القراءة المستقبلية حتى يؤدي ضغط الذاكرة إلى الإخلاء.
- هناك ثلاثة مشغلات لعملية مسح غير متزامنة:
- الوقت القائم: عندما يصل المخزن المؤقت إلى العمر المحدد بواسطة هذا الضبط، يجب وضع علامة عليه للتنظيف (أي المسح أو الكتابة إلى التخزين).
- ضغط الذاكرة: راجع
vm.dirty_ratio | vm.dirty_bytes
للحصول على التفاصيل. - إغلاق: عند إغلاق مقبض ملف، يتم مسح جميع المخازن المؤقتة غير المتزامنة إلى التخزين.
يتم التحكم في هذه العوامل من قبل أربعة ضبط. يمكن ضبط كل قابل للضبط بشكل ديناميكي ومستمر باستخدام tuned
أو sysctl
في /etc/sysctl.conf
الملف. يؤدي ضبط هذه المتغيرات إلى تحسين أداء التطبيقات.
إشعار
تم الكشف عن المعلومات التي تمت مناقشتها في هذه المقالة أثناء تمارين التحقق من صحة SAS GRID وSAS Viya. وعلى هذا النحو، تستند الضبطات إلى الدروس المستفادة من تمارين التحقق من الصحة. تستفيد العديد من التطبيقات بالمثل من ضبط هذه المعلمات.
vm.dirty_ratio | vm.dirty_bytes
تحدد هاتان الضبطتان مقدار ذاكرة الوصول العشوائي التي تم جعلها قابلة للاستخدام للبيانات المعدلة ولكن لم تتم كتابتها بعد إلى التخزين المستقر. أيهما قابل للضبط يتم تعيينه تلقائيا إلى ضبط الآخر إلى الصفر؛ ينصح RedHat بعدم تعيين أي من الضبطين يدويا إلى الصفر. يتم تعيين الخيار vm.dirty_ratio
(الافتراضي للاثنين) بواسطة Redhat إلى 20٪ أو 30٪ من الذاكرة المادية اعتمادا على نظام التشغيل، وهو مبلغ كبير بالنظر إلى بصمة الذاكرة للأنظمة الحديثة. يجب مراعاة الإعداد vm.dirty_bytes
بدلا من vm.dirty_ratio
تجربة أكثر اتساقا بغض النظر عن حجم الذاكرة. على سبيل المثال، حدد العمل المستمر مع SAS GRID 30 MiB إعدادا مناسبا لأفضل أداء إجمالي لحمل العمل المختلط.
vm.dirty_background_ratio | vm.dirty_background_bytes
تحدد هذه الضبطات نقطة البداية حيث تبدأ آلية إعادة كتابة Linux في مسح الكتل القذرة إلى تخزين ثابت. يتم تعيين Redhat افتراضيا إلى 10٪ من الذاكرة الفعلية، والتي، على نظام ذاكرة كبير، هي كمية كبيرة من البيانات لبدء المسح. مع SAS GRID كمثال، تاريخيا كانت التوصية هي تعيين vm.dirty_background
إلى حجم 1/5 من vm.dirty_ratio
أو vm.dirty_bytes
. بالنظر إلى كيفية تعيين الإعداد ل SAS GRID بقوة vm.dirty_bytes
، لا يتم تعيين قيمة محددة هنا.
vm.dirty_expire_centisecs
يحدد هذا الضبط مدى عمر المخزن المؤقت القذر قبل أن يتم وضع علامة عليه للكتابة بشكل غير متزامن. خذ حمل عمل CAS ل SAS Viya على سبيل المثال. وجد حمل عمل مسيطر على الكتابة سريع الزوال أن تعيين هذه القيمة إلى 300 سنت ثانية (3 ثوان) هو الأمثل، مع 3000 سنتي ثانية (30 ثانية) هي القيمة الافتراضية.
يشارك SAS Viya بيانات CAS في مجموعات صغيرة متعددة من بضعة ميغابايت لكل منها. بدلا من إغلاق مقابض الملفات هذه بعد كتابة البيانات إلى كل جزء، يتم ترك المقابض مفتوحة ويتم تعيين الذاكرة داخل المخازن المؤقتة داخل التطبيق. بدون إغلاق، لا يوجد تدفق حتى مرور ضغط الذاكرة أو 30 ثانية. ثبت أن انتظار ضغط الذاكرة دون المستوى الأمثل كما كان في انتظار انتهاء صلاحية مؤقت طويل. على عكس SAS GRID، الذي بحث عن أفضل معدل نقل إجمالي، بدا SAS Viya لتحسين عرض النطاق الترددي للكتابة.
vm.dirty_writeback_centisecs
مؤشر ترابط kernel flusher مسؤول عن مسح المخازن المؤقتة القذرة بشكل غير متزامن بين كل مؤشر ترابط تدفق في وضع السكون. يحدد هذا القابل للضبط المبلغ الذي يقضيه في النوم بين عمليات المسح. بالنظر إلى القيمة 3 ثوان vm.dirty_expire_centisecs
المستخدمة من قبل SAS Viya، تعيين SAS هذا ضبط إلى 100 centiseconds (1 ثانية) بدلا من الافتراضي 500 centiseconds (5 ثوان) للعثور على أفضل أداء عام.
تأثير ذاكرة التخزين المؤقت لنظام الملفات غير المذهل
عند مراعاة ضبط الذاكرة الظاهرية الافتراضية ومقدار ذاكرة الوصول العشوائي في الأنظمة الحديثة، من المحتمل أن يؤدي الحفظ مع التحديث إلى إبطاء العمليات الأخرى المرتبطة بالتخزين من منظور العميل المحدد الذي يقود حمل العمل المختلط هذا. يمكن توقع الأعراض التالية من جهاز Linux غير المذهل والثقيل بالكتابة والمحمل بذاكرة التخزين المؤقت.
- تستغرق قوائم
ls
الدليل وقتا كافيا لتظهر غير مستجيبة. - ينخفض معدل نقل القراءة مقابل نظام الملفات بشكل ملحوظ بالمقارنة مع معدل نقل الكتابة.
nfsiostat
تكتب التقارير زمن انتقال بالثوان أو أعلى.
قد تواجه هذا السلوك فقط من قبل جهاز Linux الذي يقوم بأحمال العمل المختلطة كثيفة الكتابة. علاوة على ذلك، يتم تخفيض التجربة مقابل جميع وحدات تخزين NFS التي تم تحميلها مقابل نقطة نهاية تخزين واحدة. إذا كانت التحميلات تأتي من نقطتي نهاية أو أكثر، فإن وحدات التخزين التي تشارك نقطة نهاية فقط تعرض هذا السلوك.
تم عرض تعيين معلمات ذاكرة التخزين المؤقت لنظام الملفات كما هو موضح في هذا القسم لمعالجة المشكلات.
مراقبة الذاكرة الظاهرية
لفهم ما يحدث مع الذاكرة الظاهرية وإعادة الكتابة، ضع في اعتبارك قصاصة التعليمات البرمجية التالية والإخراج. يمثل التسخ مقدار الذاكرة غير الصالحة في النظام، ويمثل الحفظ مع التحديث مقدار الذاكرة التي تتم كتابتها بنشاط إلى التخزين.
# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done`
يأتي الإخراج التالي من تجربة حيث vm.dirty_ratio
تم تعيين و vm.dirty_background
إلى 2٪ و 1٪ من الذاكرة المادية على التوالي. في هذه الحالة، بدأ المسح عند 3.8 غيغابايت، 1٪ من نظام الذاكرة 384-GiB. يشبه الحفظ مع التحديث بشكل وثيق معدل نقل الكتابة إلى NFS.
Cons
Dirty: 1174836 kB
Writeback: 4 kB
###
Dirty: 3319540 kB
Writeback: 4 kB
###
Dirty: 3902916 kB <-- Writes to stable storage begins here
Writeback: 72232 kB
###
Dirty: 3131480 kB
Writeback: 1298772 kB