الخلاصة: يقيس كلٌّ من Proxmox وZimaOS منظورًا مختلفًا من الذاكرة نفسها
قد تبدو الآلة الافتراضية في Proxmox «ممتلئة بنسبة 95%»، بينما يبلّغ ZimaOS نفسه عن استخدام نحو 30% من ذاكرة RAM. وهذا لا يعني تلقائيًا وجود تسرّب. إذ يرى المضيف الصفحات المقيمة المخصّصة للآلة الافتراضية، بينما قد يصنّف الضيف جزءًا كبيرًا من الذاكرة على أنه ذاكرة تخزين مؤقت قابلة للاسترداد أو متاحة بطريقة أخرى.
لا تُلقِ باللوم على غياب وكيل ضيف QEMU في كامل هذا الاختلاف
تقول لقطة الشاشة «لم تتم تهيئة وكيل الضيف»، لكن تفسير المنتدى يبالغ في دوره. يحسّن وكيل ضيف QEMU الاتصال بين المضيف والضيف، إلا أن Proxmox يستخدم جهاز Ballooning للحصول على معلومات تفصيلية عن ذاكرة الضيف. ويوصي Proxmox صراحةً بإبقاء جهاز Ballooning مفعّلًا لإعداد تقارير الذاكرة. راجع ذاكرة آلة Proxmox الافتراضية.
يوفّر ZimaOS على Proxmox الخط الأساسي لإعداد المحاكاة الافتراضية في ZimaOS.
داخل ZimaOS، تحقّق من الذاكرة المتاحة قبل اعتبار الاستخدام مرتفعًا
free -h
cat /proc/meminfo | head -20
docker stats --no-streamركّز على available، ونشاط مساحة التبديل، والحاويات التي تحتفظ بالذاكرة فعليًا. يستخدم Linux ذاكرة RAM الحرة عمدًا لذاكرة التخزين المؤقت لنظام الملفات؛ فالذاكرة المخزنة مؤقتًا مفيدة ويمكن استردادها عند وجود ضغط. ويُعد محاسبة الذاكرة في Linux المرجع الأساسي.
متى تصبح المشكلة مشكلة ذاكرة فعلية؟
أجرِ مزيدًا من التحقيق إذا استمرت الذاكرة المتاحة في الانخفاض، أو نمت مساحة التبديل باستمرار، أو أعيد تشغيل الحاويات، أو سجّل النواة عمليات قتل بسبب نفاد الذاكرة، أو استمرت إحدى العمليات في النمو على مدى ساعات. فالنسبة الثابتة في Proxmox وحدها لا تكفي.
يساعد متطلبات أجهزة الآلة الافتراضية في تحديد حجم الضيف بعد معرفة مجموعة العمل الفعلية.
استخدم طريقة مراقبة واحدة لمقارنة الاتجاهات
للتشخيص من أسبوع إلى آخر، لا تقارن مقياسًا للمضيف في Proxmox بمقياس في لوحة معلومات ZimaOS كما لو كانا متطابقين. اختر طبقة واحدة وتابع اتجاهها باستمرار، ثم استخدم الطبقة الأخرى لتفسير الحالات الشاذة فقط.
