الخلاصة: «يستخدم ZimaOS ذاكرة وصول عشوائي أكبر بعد الإصدار 1.6» ليست عبارة محددة بما يكفي—حدّد العملية أو الحاوية
ظل النظام بسعة 8 جيجابايت يعرض استخدامًا مرتفعًا للذاكرة بعد الانتقال من 1.6.0-beta2 إلى الإصدار المستقر. وهذا يستبعد التفسير السهل القائل إن السبب كان مجرد الحمل الإضافي للإصدار التجريبي. الخطوة المفيدة التالية هي تحديد مصدر الاستخدام: أي حاوية أو ذاكرة تخزين مؤقت أو عملية مضيفة تستحوذ على الذاكرة، وهل النظام يعاني فعلًا من ضغط الذاكرة؟
ابدأ بالذاكرة المتاحة، وليس بنسبة لوحة المعلومات فقط
free -h
docker stats --no-stream
ps aux --sort=-%mem | head -20
dmesg | grep -i -E 'oom|out of memory'يستخدم Linux ذاكرة الوصول العشوائي غير النشطة لأغراض التخزين المؤقت. ويختلف ارتفاع رقم «المستخدمة» مع سلامة الذاكرة available وعدم وجود ضغط ناتج عن نفاد الذاكرة أو التبديل، عن وجود تسرّب. وتُعد وثائق احتساب الذاكرة في Linux المرجع الأساسي.
إجماليات الحاويات تفسّر جزءًا فقط من المضيف
تُظهر لقطة الشاشة عدة حاويات تستهلك مئات الميجابايتات لكل منها، لكن جمعها لا يساوي بالضرورة إجمالي المضيف بأكمله. فمقاييس ذاكرة Docker، وذاكرة التخزين المؤقت للنواة، وذاكرة الصفحات المؤقتة، والخدمات غير التابعة للحاويات، تمثل طبقات منفصلة من احتساب الذاكرة. وتشرح إحصاءات حاويات Docker طريقة عرض الحاويات.
لا تفترض أن الإصدار المستقر 1.6.0 تضمن إصلاحًا عامًا لتسرّب الذاكرة
تسرد ملاحظات الإصدار الحالية لـ 1.6.0 إصلاحات متعلقة بالتخزين، وبدء تشغيل Docker، والملفات، والشبكة، لكنها لا توثّق إصلاحًا واسعًا لتسرّب الذاكرة. لذلك ينبغي أن يستند التشخيص الحالي إلى الأدلة، بدلًا من القول: «قم بالترقية وستُحل المشكلة».
توفّر تغييرات ZimaOS 1.6 سياق الإصدار الحالي.
ما الذي يُعد تسرّبًا حقيقيًا؟
راقب العملية نفسها على مدار عدة ساعات. يصبح التسرّب أكثر احتمالًا عندما تنمو إحدى العمليات باطراد، أو تتقلص الذاكرة المتاحة، أو يزداد استخدام الذاكرة التبادلية، أو تبدأ النواة في إنهاء العمليات. أما إذا استقر استخدام الذاكرة وظل النظام سريع الاستجابة، فقد يكون الأمر ببساطة مجموعة عمل مستقرة أكبر.
تساعدك متطلبات تطبيقات ZimaOS في تحديد ما إذا كانت مجموعة التطبيقات المثبتة كبيرة جدًا بالنسبة إلى مضيف بسعة 8 جيجابايت.
