ما هو vm.min_free_kbytes وكيفية ضبطه؟

كيف يعمل vm.min_free_kbytes

قد يحتاج النظام إلى تخصيصات الذاكرة لضمان حسن سير النظام نفسه. إذا سمحت النواة بتخصيص كل الذاكرة ، فقد تواجه صعوبة عند الحاجة إلى ذاكرة لعمليات منتظمة للحفاظ على تشغيل نظام التشغيل بسلاسة. هذا هو السبب في أن النواة توفر vm.min_free_kbytes القابل للضبط. سيجبر الضبط مدير ذاكرة kernel على الاحتفاظ بمقدار X على الأقل من الذاكرة الخالية. هنا التعريف الرسمي من توثيق نواة لينوكس : يستخدم هذا لإجبار Linux VM على الاحتفاظ بأقل عدد ممكن من الكيلوبايتات المجانية. يستخدم الجهاز الظاهري هذا الرقم لحساب قيمة العلامة المائية [WMARK_MIN] لكل منطقة منخفضة الذاكرة في النظام. تحصل كل منطقة منخفضة الذاكرة على عدد من الصفحات المجانية المحجوزة بناءً على حجمها. بعض مقدار الحد الأدنى من الذاكرة مطلوب لتلبية تخصيصات PF_MEMALLOC؛ إذا قمت بضبط هذا على أقل من 1024 كيلو بايت ، فسيصبح نظامك مكسورًا بمهارة وعرضة للتوقف في ظل الأحمال العالية. سيؤدي ضبط هذا المستوى العالي جدًا إلى تشغيل جهازك على الفور.

التحقق من صحة vm.min_free_kbytes Works

من أجل اختبار أن إعداد min_free_kbytes يعمل كما هو مُصمم ، قمت بإنشاء مثيل ظاهري من نوع linux بذاكرة وصول عشوائي (RAM) تبلغ 3.75 جيجابايت فقط. استخدم الأمر المجاني أدناه لتحليل النظام:

النظر إلى أداة الذاكرة المجانية أعلاه باستخدام العلامة -m لطباعة القيم بالميغابايت. تبلغ الذاكرة الإجمالية 3.5 إلى 3.75 جيجا بايت من الذاكرة. يتم استخدام 121 ميجا بايت من الذاكرة ، 3.3 جيجا بايت من الذاكرة خالية ، 251 ميجا بايت تستخدم بواسطة ذاكرة التخزين المؤقت. ويتوفر 3.3 جيجا بايت من الذاكرة.

الآن سنقوم بتغيير قيمة vm.min_free_kbytes ونرى تأثير ذلك على ذاكرة النظام. سنقوم بترديد القيمة الجديدة إلى نظام الملفات الظاهري proc لتغيير قيمة معلمة kernel كما هو موضح أدناه:

يمكنك أن ترى أنه تم تغيير المعلمة إلى 1.5 غيغابايت تقريبًا ودخلت حيز التنفيذ. الآن دعونا نستخدم مجانا الأمر مرة أخرى لرؤية أي تغييرات يتعرف عليها النظام.

لا يتم تغيير الذاكرة الخالية وذاكرة التخزين المؤقت بواسطة الأمر ، ولكن يتم عرض حجم الذاكرة على شكل متوفرة تم تخفيضه من 3327 إلى 1222 ميغا بايت. وهو تخفيض تقريبي للتغيير في المعلمة إلى 1.5 جيجابايت دقيقة من الذاكرة الخالية.

لنقم الآن بإنشاء ملف بيانات بحجم 2 غيغابايت ثم نرى ما تؤديه قراءة هذا الملف في ذاكرة التخزين المؤقت إلى القيم. فيما يلي كيفية إنشاء ملف بيانات بحجم 2 جيجابايت في سطرين من برنامج bash النصي أدناه. سينشئ البرنامج النصي ملفًا عشوائيًا بحجم 35 ميجا بايت باستخدام الأمر dd ثم نسخه 70 مرة إلى ملف جديد ملف البيانات انتاج:

دعنا نقرأ الملف ونتجاهل المحتويات من خلال قراءة الملف وإعادة توجيهه إلى / dev / null كما هو موضح أدناه:

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

تحليل النتائج أعلاه. لا يزال لدينا 1.8 جيجا بايت من الذاكرة الخالية ، لذا فقد قامت النواة بحماية جزء كبير من الذاكرة على أنها محجوزة بسبب إعداد min_free_kbytes الخاص بنا. استخدمت ذاكرة التخزين المؤقت 1691 ميجابايت ، وهو أقل من الحجم الإجمالي لملف البيانات لدينا وهو 2.3 جيجابايت. على ما يبدو كله ملف البيانات لا يمكن تخزينها في ذاكرة التخزين المؤقت بسبب نقص الذاكرة المتاحة لاستخدامها في ذاكرة التخزين المؤقت. يمكننا التحقق من عدم تخزين الملف بأكمله في ذاكرة التخزين المؤقت ولكن توقيت المحاولات المتكررة لقراءة الملف. إذا تم تخزينه مؤقتًا ، فسيستغرق الأمر جزءًا من الثانية لقراءة الملف. فلنجربها.

استغرقت قراءة الملف ما يقرب من 20 ثانية مما يعني أنه من شبه المؤكد أنه لم يتم تخزينها مؤقتًا بالكامل.

كتحقق نهائي واحد ، فلنقلل vm.min_free_kbytes للسماح لذاكرة التخزين المؤقت للصفحة بتوفير مساحة أكبر للعمل ويمكننا أن نتوقع رؤية ذاكرة التخزين المؤقت تعمل وقراءة الملف تزداد سرعة.

مع الذاكرة الإضافية المتاحة للتخزين المؤقت ، انخفض وقت قراءة الملف من 20 ثانية قبل ذلك إلى .364 ثانية مع كل ذلك في ذاكرة التخزين المؤقت.

لدي فضول للقيام بتجربة أخرى. ماذا يحدث لاستدعاءات malloc لتخصيص ذاكرة من برنامج سي في مواجهة هذا الإعداد العالي حقًا vm.min_free_kbytes. هل ستفشل في malloc؟ هل سيموت النظام؟ قم أولاً بإعادة تعيين إعداد vm.min_free_kbytes إلى القيمة العالية حقًا لاستئناف تجاربنا:

دعونا ننظر مرة أخرى إلى ذاكرتنا الخالية:

نظريًا ، لدينا 1.9 جيجا بايت مجانًا و 515 ميجا بايت متاح. دعنا نستخدم برنامج اختبار الإجهاد المسمى الإجهاد- ng من أجل استخدام بعض الذاكرة ومعرفة أين نفشل. سنستخدم جهاز اختبار vm ونحاول تخصيص 1 جيجا بايت من الذاكرة. نظرًا لأننا حجزنا 1.5 غيغابايت فقط على نظام 3.75 غيغابايت ، أعتقد أن هذا يجب أن يعمل.

دعونا نجربها مرة أخرى مع المزيد من العمال ، يمكننا أن نجرب 1 ، 2 ، 3 ، 4 عمال وفي مرحلة ما من المفترض أن تفشل. في الاختبار الذي أجريته ، نجح في اجتياز عاملين وعاملين لكنه فشل مع 3 عمال.

دعنا نعيد ضبط vm.min_free_kbytes إلى رقم منخفض ونرى ما إذا كان ذلك يساعدنا في تشغيل 3 ضغوطات للذاكرة بسعة 1 غيغابايت لكل منها على نظام 3.75 غيغابايت.

هذه المرة تم تشغيلها بنجاح دون أخطاء ، لقد جربتها مرتين دون مشاكل. لذا يمكنني أن أستنتج أن هناك اختلافًا سلوكيًا في وجود المزيد من الذاكرة المتاحة لـ malloc ، عندما يتم ضبط قيمة vm.min_free_kbytes على قيمة أقل.

الإعداد الافتراضي لـ vm.min_free_kbytes

القيمة الافتراضية للإعداد على نظامي هي 67584 والتي تمثل حوالي 1.8٪ من ذاكرة الوصول العشوائي على النظام أو 64 ميجابايت. لأسباب تتعلق بالسلامة في نظام متقلب بشدة ، فإنني أميل إلى زيادته قليلاً ربما إلى 128 ميجابايت للسماح بمزيد من الذاكرة الخالية المحجوزة ، ولكن بالنسبة للاستخدام المتوسط ​​، تبدو القيمة الافتراضية معقولة بدرجة كافية. تحذر الوثائق الرسمية من جعل القيمة عالية جدًا. ربما لا يكون تعيينه على 5 أو 10٪ من ذاكرة الوصول العشوائي للنظام هو الاستخدام المقصود للإعداد ، وهو مرتفع جدًا.

إعداد vm.min_free_kbytes للنجاة من عمليات إعادة التشغيل

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

استنتاج

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