الـ VM عندك واخدة 32GB RAM… لكن الـ ESXi Host بدأ يعاني من نقص الذاكرة ؟!

 

 

 

 

الـ VM عندك واخدة 32GB RAM… لكن الـ ESXi Host بدأ يعاني من نقص الذاكرة ؟!

هل تعلم أن ESXi يستطيع استعادة جزء من الـ RAM من داخل الـ Virtual Machine نفسها بدون أن يقوم بإيقافها؟

هنا يأتي دور تقنية مهمة جدًا في VMware vSphere اسمها:

ESXi Memory Ballooning

والأهم… أن Ballooning ليس مجرد "سحب RAM" من الـ VM، بل آلية ذكية يستخدمها ESXi عندما يحتاج إلى إعادة توزيع الذاكرة بين الـ Virtual Machines.

━━━━━━━━━━━━━━━━━━
أولًا: ما هو Memory Ballooning؟
━━━━━━━━━━━━━━━━━━

عندما يكون لديك ESXi Host يحتوي على عدة Virtual Machines، قد يحدث Memory Overcommitment.

مثال:

ESXi Host
RAM = 64 GB

وعليه:

VM01 → 32 GB
VM02 → 24 GB
VM03 → 16 GB

إجمالي الذاكرة المخصصة:
72 GB

هنا تم تخصيص RAM للـ VMs أكثر من الـ Physical RAM الموجودة في الـ Host.

لكن هذا لا يعني بالضرورة أن هناك مشكلة مباشرة؛ لأن الـ VMs قد لا تستخدم كل الذاكرة المخصصة لها في نفس الوقت.

عندما يبدأ ESXi في مواجهة Memory Pressure، يبدأ VMkernel في استخدام تقنيات Memory Reclamation، ومن بينها:

Ballooning
Memory Compression
VMkernel Swapping

━━━━━━━━━━━━━━━━━━
كيف يعمل Ballooning؟
━━━━━━━━━━━━━━━━━━

داخل الـ VM يوجد VMware Balloon Driver يسمى:

vmmemctl

ويأتي ضمن VMware Tools.

عندما يحتاج ESXi إلى استعادة RAM:

الـ ESXi Host يطلب من الـ Balloon Driver استعادة جزء من الذاكرة.

يقوم vmmemctl بـ "Inflate" الـ Balloon داخل الـ Guest OS.

الـ Guest OS يشعر بوجود Memory Pressure.

نظام التشغيل نفسه يبدأ في اختيار الصفحات الأقل أهمية وإعادة استخدامها أو Paging/Swapping حسب حالته.

الذاكرة التي تم تحريرها تصبح متاحة للـ ESXi Host.

يستطيع ESXi إعادة توزيع هذه الذاكرة على VM أخرى تحتاج إليها.

بمعنى أبسط:

ESXi لا يقوم بشكل عشوائي بأخذ أي Page من الـ VM.

بل يجعل الـ Guest OS نفسه يشارك في عملية اختيار الذاكرة التي يمكن التخلص منها.

وهذه نقطة مهمة جدًا في فهم Ballooning.

━━━━━━━━━━━━━━━━━━
لماذا يستخدم ESXi Ballooning؟
━━━━━━━━━━━━━━━━━━

لأن ESXi يريد إدارة الـ Physical RAM بأكبر قدر ممكن من الكفاءة.

بدلًا من أن تكون لديك:

RAM allocated but unused

في VM معينة…

يمكن للـ ESXi أن يستعيد جزءًا منها مؤقتًا ويعطيها لـ VM أخرى تحتاجها.

وهذا مفيد جدًا في بيئات الـ Virtualization التي تحتوي على عدد كبير من الـ VMs.

━━━━━━━━━━━━━━━━━━
هل Ballooning شيء سيئ؟
━━━━━━━━━━━━━━━━━━

ليس بالضرورة.

وجود Ballooning لا يعني تلقائيًا أن الـ ESXi Host به مشكلة.

إذا حدث Ballooning بشكل محدود ومؤقت أثناء وجود Memory Pressure، فقد يكون جزءًا طبيعيًا من آلية إدارة الذاكرة في ESXi.

لكن…

Ballooning المستمر أو المرتفع يستحق التحقيق.

خصوصًا إذا كان مصحوبًا بـ:

Guest OS Paging
VMkernel Swapping
Memory Compression
Application Slowdown
High Memory Utilization
VM Performance Issues

في هذه الحالة يجب معرفة سبب Memory Pressure بدلًا من مجرد تعطيل Ballooning.

━━━━━━━━━━━━━━━━━━
Ballooning vs Swapping
━━━━━━━━━━━━━━━━━━

وهنا يقع خطأ شائع جدًا:

Ballooning ≠ ESXi Swap

في Ballooning:

ESXi يطلب من Guest OS تحرير الذاكرة من خلال vmmemctl.

أما في VMkernel Swapping:

ESXi نفسه يقوم بكتابة صفحات من ذاكرة الـ VM إلى Swap File على الـ Datastore.

والـ Swapping عادةً أكثر تأثيرًا على Performance بسبب الوصول إلى Storage بدل RAM.

لذلك عند تحليل مشكلة Memory Performance يجب ألا تكتفي بمشاهدة Memory Usage فقط.

يجب معرفة:

هل يوجد Ballooning؟
هل يوجد ESXi Swapping؟
هل يوجد Memory Compression؟
وهل الـ Guest OS نفسه يقوم بالـ Paging؟

━━━━━━━━━━━━━━━━━━
وماذا عن Memory Compression؟
━━━━━━━━━━━━━━━━━━

قبل أن يصل ESXi إلى مستويات أكثر تكلفة من استعادة الذاكرة، يمكنه استخدام Memory Compression.

الفكرة ببساطة:

بدل كتابة Page كاملة إلى Storage، يمكن ضغط بعض صفحات الذاكرة بحيث تشغل مساحة أقل.

وبالتالي يستطيع ESXi الاحتفاظ بمزيد من البيانات داخل RAM.

لذلك يمكن أن ترى في esxtop مؤشرات مثل:

ZIP/s
UNZIP/s
CACHEUSD

وارتفاعها قد يشير إلى أن ESXi يستخدم Memory Compression نتيجة ضغط الذاكرة.

━━━━━━━━━━━━━━━━━━
كيف أعرف أن الـ VM تستخدم Ballooning؟
━━━━━━━━━━━━━━━━━━

هنا يأتي دور أداة كل VMware Administrator لازم يعرفها:

esxtop

على الـ ESXi Host:

esxtop

ثم:

m

للدخول إلى Memory View.

ابحث عن:

MCTLSZ
MCTLTGT
MCTLMAX

MCTLSZ

يمثل كمية الـ Guest Physical Memory التي تم استعادتها بواسطة Balloon Driver.

كلما زادت القيمة، فهذا يعني أن الـ ESXi يقوم باستعادة كمية أكبر من ذاكرة الـ VM عن طريق Ballooning.

MCTLTGT

الـ Target الذي يحاول ESXi الوصول إليه من خلال Ballooning.

MCTLMAX

الحد الأقصى للذاكرة التي يمكن للـ Balloon Driver استعادتها.

كما يمكنك استخدام:

SWCUR

لمعرفة مقدار الذاكرة الموجودة حاليًا في VMkernel Swap.

و:

SWR/s
SWW/s

لمراقبة معدلات Swap In / Swap Out.

━━━━━━━━━━━━━━━━━━
مثال عملي
━━━━━━━━━━━━━━━━━━

لنفترض أن لديك:

ESXi Host:
64 GB RAM

VM01:
32 GB

VM02:
24 GB

VM03:
16 GB

Total Configured:
72 GB

الـ VMs لا تستخدم الـ 72GB بالكامل.

لكن VM02 بدأت تحتاج إلى RAM إضافية بسبب Database Workload.

إذا كانت الذاكرة المتاحة على الـ Host غير كافية، يمكن لـ ESXi أن يبدأ Memory Reclamation.

قد ترى مثلًا:

MCTLSZ = 4096 MB

وهذا يعني أن حوالي 4GB من Guest Physical Memory يتم استعادتها بواسطة Balloon Driver.

إذا استمر ضغط الذاكرة واحتاج ESXi إلى إجراءات إضافية، قد تظهر مؤشرات Compression أو Swapping.

وهنا يجب أن تبدأ عملية Troubleshooting.

━━━━━━━━━━━━━━━━━━
أهم نقطة: لا تنظر إلى "Consumed Memory" فقط
━━━━━━━━━━━━━━━━━━

قد ترى VM في vCenter وتجد:

Consumed Memory = 90%

فتعتقد أن الـ VM تستخدم تقريبًا كل الـ RAM.

لكن الصورة ليست بهذه البساطة.

هناك فرق بين:

Allocated / Consumed Memory

وبين:

Active Memory

فالـ Guest OS قد يكون قد حصل على صفحات من الذاكرة ثم أصبح بعضها غير نشط أو مستخدمًا كـ Cache.

لهذا السبب لا يجب اتخاذ قرار بزيادة RAM أو تقليلها اعتمادًا على رقم واحد فقط.

يجب النظر إلى:

Active Memory
Consumed Memory
Ballooning
Compression
Swapping
Guest OS Paging
Application Performance

━━━━━━━━━━━━━━━━━━
مشكلة شائعة جدًا: Memory Limit
━━━━━━━━━━━━━━━━━━

أحيانًا تجد ESXi Host لديه RAM متاحة، ومع ذلك ترى Ballooning أو Swapping على VM.

لماذا؟

قد يكون هناك Memory Limit تم وضعه على الـ VM.

مثال:

VM Configured Memory:
16 GB

لكن Memory Limit:
8 GB

هنا الـ Guest OS قد يعتقد أن لديه 16GB، بينما ESXi يفرض حدًا أقل على الذاكرة التي يمكن للـ VM الحصول عليها مباشرة.

وهذا قد يؤدي إلى Memory Reclamation أو Swapping حتى لو كان الـ Host نفسه لديه RAM متاحة.

لذلك:

لا تفترض دائمًا أن Ballooning = Host RAM shortage.

راجع أيضًا:

VM Settings
→ Edit Settings
→ Resources
→ Memory
→ Limit

━━━━━━━━━━━━━━━━━━
هل يمكن تعطيل Ballooning؟
━━━━━━━━━━━━━━━━━━

نعم، لكن السؤال الصحيح ليس:

"كيف أعطل Ballooning؟"

بل:

"لماذا يحدث Ballooning أصلًا؟"

Broadcom توضح أن تعطيل Balloon Driver يجب أن يكون Case-by-Case، وليس إجراءً عامًا.

ومن الطرق الموجودة:

Reserve All Guest Memory

من:

VM Settings
→ Resources
→ Memory
→ Reserve all guest memory

أو في حالات محددة يمكن استخدام إعداد:

sched.mem.maxmemctl = 0

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

لأن منع Ballooning لا يلغي مشكلة Memory Pressure.

قد يدفع ESXi إلى استخدام آليات أخرى مثل Host/VMkernel Swapping، والتي قد يكون تأثيرها على الأداء أكبر.

━━━━━━━━━━━━━━━━━━
VMware Tools مهمة جدًا
━━━━━━━━━━━━━━━━━━

الـ Balloon Driver:

vmmemctl

جزء من VMware Tools.

لذلك في حالة عدم وجود VMware Tools أو عدم عمل الـ Balloon Driver، لن يستطيع ESXi استخدام Ballooning لهذه الـ VM.

وهنا يجب التأكد من:

VMware Tools Installed
VMware Tools Running
Driver Available
VM Compatibility
Guest OS Health

━━━━━━━━━━━━━━━━━━
ماذا أفعل إذا كان عندي Ballooning مستمر؟
━━━━━━━━━━━━━━━━━━

اتبع هذا الـ Troubleshooting Flow:

Check Host Memory

هل يوجد Memory Overcommitment؟

Check VM Memory Allocation

هل الـ VMs مخصصة لها RAM أكبر من احتياجاتها الفعلية؟

Check Active Memory

هل الـ VM تستخدم فعليًا الـ RAM المخصصة لها؟

Check Ballooning

MCTLSZ
MCTLTGT
MCTLMAX

Check Compression

ZIP/s
UNZIP/s
CACHEUSD

Check Swapping

SWCUR
SWR/s
SWW/s

Check VM Memory Limit

هل يوجد Limit أقل من الـ Configured Memory؟

Check Guest OS

Windows:

Task Manager
Resource Monitor
Performance Monitor

Linux:

free -h
vmstat
sar -r
top

Check Application

هل الـ Application نفسها تحتاج RAM أكثر؟

Review Host Capacity

هل تحتاج إلى:

RAM Upgrade
Additional Host
VM Redistribution
Resource Optimization

━━━━━━━━━━━━━━━━━━
أخطر خطأ ممكن تعمله
━━━━━━━━━━━━━━━━━━

أن ترى

Ballooning = 4GB

فتقول

VMware فيه مشكلة

أو تقوم مباشرةً بتعطيل Ballooning.

هذا ليس Troubleshooting.

الرقم وحده لا يكفي.

اسأل:

هل الـ VM بطيئة؟

هل يوجد Guest Paging؟

هل يوجد Swap؟

هل يوجد Compression؟

هل يوجد Memory Overcommitment؟

هل يوجد Memory Limit؟

هل الـ VM Oversized؟

هل الـ Host يحتاج RAM إضافية؟

هنا تبدأ الـ Troubleshooting الحقيقية.

━━━━━━━━━━━━━━━━━━
الخلاصة
━━━━━━━━━━━━━━━━━━

Memory Ballooning هو أحد أدوات ESXi لإدارة الذاكرة وإعادة توزيعها بين الـ VMs.

ويعتمد على:

vmmemctl

داخل VMware Tools.

وعندما يحدث Memory Pressure، يستطيع ESXi استخدام مجموعة من الآليات، منها:

Ballooning
Compression
Swapping

والهدف هو الحفاظ على أكبر قدر ممكن من الـ RAM للـ Workloads التي تحتاجها.

لكن:

Ballooning ليس المشكلة بحد ذاته.

المشكلة عندما يصبح مستمرًا أو مرتفعًا ويبدأ في التأثير على أداء الـ VM.

لذلك كـ VMware Administrator:

لا تراقب RAM Usage فقط…

راقب Memory Behavior بالكامل.

━━━━━━━━━━━━━━━━━━
VMware Admin Cheat Sheet

Ballooning → MCTLSZ

Balloon Target → MCTLTGT

Balloon Maximum → MCTLMAX

Compression → ZIP/s / UNZIP/s

Current Swap → SWCUR

Swap Read → SWR/s

Swap Write → SWW/s

Active Memory → %ACTV

Configured VM Memory → MEMSZ

━━━━━━━━━━━━━━━━━━

لو أنت شغال VMware / vSphere، احفظ الجملة دي:

"High RAM usage does not always mean Memory Pressure — and Ballooning does not always mean a problem."

المهم هو أن تفهم ماذا يفعل ESXi بالذاكرة ولماذا.