لماذا يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم بعد تغيير ملف Compose؟

يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم عندما لا يكون إعداد Compose المعدَّل قد طُبِّق على cgroup المباشر لذلك الحاوي.

لا يؤدي تغيير YAML إلى تعديل حاوٍ موجود تلقائيًا، كما أن إعادة التشغيل العادية تبدأ الحاوي نفسه بإعدادات التكوين نفسها التي أُنشئ بها. وينشأ الالتباس أيضًا من مقارنة حد ذاكرة صارم بحجز أو سماح بالتبديل أو نطاق systemd للنظام الأب أو إعداد كومة التطبيق. شخّص قيمة cgroup الفعلية ومعرّف الحاوي قبل استنتاج أن Docker تجاهل التغيير.

اقرأ حد Cgroup المباشر بدلًا من الوثوق بملف YAML

سجّل معرّف الحاوي ووقت الإنشاء ومخرجات فحص Docker وإصدار cgroup وملفات التحكم في الذاكرة التي تستخدمها العملية قيد التشغيل.

تعرّف نواة Linux memory.max بوصفه الحد الصارم لذاكرة cgroup، بينما يفرض memory.high ضغط الاسترداد من دون أن يعمل بوصفه السقف المطلق نفسه.

إذا ظلّت القيمة القديمة موجودة في cgroup المباشر، فهذا يعني أن التكوين لم يُطبَّق. وإذا احتوت على القيمة الجديدة لكن اختلفت عنها أدوات المراقبة، فتحقق من الوحدات وحساب ذاكرة التخزين المؤقت والتبديل ومقاييس مستوى التطبيق.

ميّز بين إعادة التشغيل وإعادة إنشاء الحاوي

قارن معرّف الحاوي قبل الأمر المستخدم لنشر التغيير وبعده. وسجّل ما إذا كان الأمر هو restart أو up أو create أو إجراءً من واجهة NAS أو تحديثًا مباشرًا عبر Docker.

يوضح Docker أن إعادة تشغيل Compose لا تطبّق تغييرات التكوين، لأنها تعيد تشغيل حاويات الخدمة الحالية.

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

تحقق من نموذج Compose النهائي وحقل الذاكرة

اعرض تكوين Compose الفعلي بعد تطبيق جميع الملفات والملفات التعريفية واستبدالات البيئة. وتحقق مما إذا كان الحد يخص الخدمة النشطة.

تعرّف مواصفة Compose mem_limit بوصفه حد ذاكرة للخدمة، وتتطلب الاتساق عند التصريح أيضًا بحدود نشر مكافئة.

لا يؤدي وجود قيمة في ملف تجاوز غير مستخدم أو ملف تعريفي غير نشط أو خدمة مكتوبة بشكل خاطئ أو واجهة Stack مختلفة إلى تغيير النموذج المنشور. قارن التكوين المعروض مع فحص Docker.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

افصل بين الحد الصارم والحجز والتبديل

سجّل حد الذاكرة الصارم والحجز أو الحد المرن وحد التبديل والاستخدام الحالي وذروة الاستخدام وأحداث نفاد الذاكرة. ولا تتعامل مع كل قيمة مرتبطة بالذاكرة على أنها سقف واحد.

تميّز وثائق التحكم في موارد systemd بين MemoryHigh وMemoryMax، وتوضح أن cgroups الأب يمكنها فرض حدود إضافية على الخدمات والحاويات.

قد يبدو أن الحاوي يتجاوز الحجز لأن الحجز ليس هو الحد الأقصى الصارم نفسه. كما يمكنه استهلاك مساحة تبديل أو ذاكرة تخزين مؤقت للصفحات قد تستبعدها بعض لوحات المعلومات أو تعرضها بشكل منفصل.

تحقق مما إذا كانت كومة وقت التشغيل تستخدم سقفًا خاصًا بها

بالنسبة إلى تطبيقات Java، سجّل اكتشاف JVM المتوافق مع الحاويات والحد الأقصى للكومة والذاكرة المباشرة والذاكرة الوصفية ومكدسات مؤشرات الترابط والخيارات التي تمررها صورة التطبيق أو تكوينه.

توثّق Oracle أن JVM يحدد حجم كومة الذاكرة استنادًا إلى قيود الذاكرة المتاحة، وتتيح لـ MaxRAMPercentage ضبط نسبة الكومة.

قد لا يؤدي تغيير حد الحاوي إلى حجم كومة التطبيق المتوقع عندما يظل الخيار -Xmx الصريح أو النسبة المئوية محددًا. كما أن ذاكرة الكومة ليست إجمالي استخدام العملية للذاكرة.

تحقق من حدود Node.js وغيرها على مستوى التطبيق

افحص خيارات وقت التشغيل ومتغيرات البيئة وعدد العاملين وذاكرات التخزين المؤقت وأهداف الذاكرة الداخلية. وقارنها بحد نظام التشغيل.

توثّق Node.js أن max-old-space-size هو حد لكومة V8، وقد يظل دون تغيير حتى بعد حصول الحاوي على سماح cgroup أكبر أو أصغر.

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

طبّق تغييرًا واحدًا وتحقق منه أثناء تحميل مضبوط

اعرض نموذج Compose النهائي، وأعد إنشاء الخدمة المتأثرة فقط، وتأكد من معرّف الحاوي الجديد وcgroup المباشر، ثم شغّل حمولة محدودة مع مراقبة الاستخدام وأحداث نفاد الذاكرة.

تشرح مقالة ZimaSpace Tech & AI Hub ما يحدث عند بلوغ الحاوي حدًا نشطًا؛ بينما تركز هذه المقالة على إثبات أن الحد المعدّل نُشر فعليًا.

تُحل المشكلة عندما يتطابق التكوين المعروض وفحص الحاوي وملفات cgroup وكومة وقت التشغيل وحد الفشل الملحوظ مع السياسة المقصودة بعد إعادة التشغيل.

الأسئلة الشائعة

هل تؤدي إعادة تشغيل الحاوي إلى تطبيق حد ذاكرة Compose المعدّل؟

لا. تستخدم إعادة التشغيل عادةً تكوين الحاوي الحالي نفسه. أعد إنشاء الخدمة أو استخدم تحديثًا مباشرًا مدعومًا.

هل يمكن للحاوي تجاوز حد ذاكرته الصارم مؤقتًا؟

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

لماذا لا يزال التطبيق يعرض حجم الكومة القديم؟

قد يحتوي وقت تشغيل التطبيق على خيار كومة صريح، أو قد يحسب نسبة مئوية عند بدء التشغيل فقط. أعد إنشاء التطبيق أو أعد تشغيله بعد التحقق من حد الحاوي.