تب monitoring ماشین مجازی vCenter اطلاعات بسیار مفیدی را در مورد منابع مختلف استفاده شده توسط آن ارائه می دهد. یکی از این منابع memory می باشد که شامل Metric های مختلفی است و ابتدای امر کمی گیج کننده به نظر می رسد که بدانیم این متریک ها چه هستند و با آنها چه کاری باید انجام داد.


ما در اینجا قصد نداریم همه آنها را شرح دهیم، اما روی موارد اصلی که به احتمال زیاد برای troubleshooting استفاده می شوند تمرکز خواهیم کرد.


برای اینکه سردرگم نشوید کار را با چند اصطلاح شروع می کنیم.

Host physical memory: به حافظه ای اطلاق می شود که برای هایپروایزر به صورت available در سیستم قابل مشاهده است.

Guest physical memory: به حافظه ای اطلاق می شود که برای سیستم عامل مهمان در حال اجرا در ماشین مجازی قابل مشاهده است.

Guest virtual memory: به فضای آدرس مجازی پیوسته ای(continuous virtual address) اشاره دارد که توسط سیستم عامل مهمان به اپلیکیشن ها ارائه می شود. Guest virtual memory حافظه ای است که برای اپلیکیشن های در حال اجرا در درون VM قابل مشاهده است. Guest virtual memory توسط host physical memory پشتیبانی می شود به این معنی که هایپروایزر یک mapping از guest به هاست را انجام می دهد.

تب monitoring مربوط به VM در مورد memory شامل آیتم ها یا متریک های Consumed، active، Ballooned و Granted می باشد.
برای افزودن متریک های جدید کافیست لینک Chart options را کلیک کرده و متریک های مورد نظرتان را تیک بزنید. سپس می‌توانید آن را ذخیره کنید تا بعداً با کلیک کردن روی Save option as به آن دسترسی سریع داشته باشید.

خب، اکنون اجازه دهید با متریک های مموری کار را شروع کنیم.

Consumed

این متریک برای اندازه گیری مقدار مموری اختصاص داده شده(memory allocated) به VM استفاده می شود. consumed memory نشان‌دهنده مقدار مموری هاست است که در صورت درخواست به VM تخصیص داده شده، منهای صرفه‌جویی‌های(saving) انجام شده با کمک inter-VM TPS است.


روش محاسبه consumed host memory بدین صورت است که تعداد بلوک های unique ای را که VM به آن دسترسی دارد، در شرایطی که بلوک مشترک را بر تعداد ماشین‌های مجازی که به آن دسترسی دارند، تقسیم می‌کند و سپس کل را در اندازه بلوک ضرب کنید(4K).
در زیر یک مثال خوب از VMware documentation center را برای شما آورده ایم. Vm شماره یک به 3 بلوک منحصر به فرد دسترسی دارد. اما بلوک شماره 1 با ماشین مجازی 2 به اشتراک گذاشته شده است.

Consumed memory = 2 x 4K + 1 x (4K/2) = 10K

اگر TPS غیرفعال می بود، بلوک b دو بار در مموری هاست نوشته می شد بنابراین مقدار حافظه مصرفی VM شماره یک، 12k می شد. توجه داشته باشید که transparent page sharing فقط برای intra-VM sharing آنهم به دلایل امنیتی فعال است. بنابراین اگر تنظیمات را تغییر ندهید، ماشین‌های مجازی memory page های هاست را به اشتراک نمی‌گذارند.


وقتی یک VM، به memory page ای را که بدان تخصیص داده نشده، دسترسی پیدا می کند، ESXi مموری را بدان اختصاص می دهد و آن را در متریک «consumed» قرار می دهد. ولی این موضوع برای هاست بسیار دشوار است که بداند چه زمانی ماشین مجازی page را به guest در واقع deallocate کند چراکه حتی اگر از آن استفاده هم نشود در مموری هاست باقی می ماند و همچنان در نمودار consumed نشان داده می شود.
به همین دلیل است که شما اغلب تفاوت زیادی بین حافظه Active و Consumed مشاهده خواهید کرد و اینجاست که روش‌های احیای حافظه یا memory reclamation در صورت کمبود رم وارد عمل می‌شوند (در ادامه در این مورد بیشتر توضیح خواهیم داد).

Granted

از این متریک برای اندازه گیری مموری ماشین مجازی استفاده کنید. این مقدار ح guest physical memory را که در اختیار ماشین مجازی قرار داده شده است، محاسبه می کند. تا زمانی که یک بار آن حد مموری اختصاص داده شده را دسترسی پیدا نکند یا از آن استفاده نکند، مموری به VM تعلق یا grant نمی شود. بر خلاف consumed memory تمرکز به جای هاست، به VM معطوف می شود. Granted memory از آنجایی که به guest physical memory نگاه می کند، intra-VM page sharing را در نظر نمی گیرد.


اگر بخواهید چندین VM را اجرا کنید که از TPS برای share memory استفاده می کنند، متوجه می شوید که حافظه مصرفی با از بین رفتن consumed memory کاهش می یابد در حالی که مموری grant شده ثابت باقی می ماند. این الگو را در نمودار زیر به وضوح می بینید.

Active

این متریک کمی گیج کننده خواهد بود. قبل از انجام اقدامات، مهم است که بدانیم معنی آن چیست زیرا می تواند تأثیرات منفی غیرمنتظره ای بر عملکرد VM داشته باشد. این نام صریح و خیلی واضح به نظر می رسد، شما فکر می کنید که "active memory" به معنی مموری واقعی است که مهمان در حال حاضر از آن استفاده می کند. ولی متأسفانه، آنقدرها هم که به نظر می رسد ساده نیست.
هدف این متریک در واقع تخمین میزان استفاده مهمان است. برای دستیابی به این هدف، هاست باید هر page ای را که Touch می شود مانیتور کند، گرچه overhead در انجام این کار ارزش تلاش را ندارد. در عوض، هاست از مکانیزم sampling برای تخمین مقدار حافظه ای که Touch شده، استفاده می کند. بنابراین نشان دهنده چیزی است که VMkernel تصور می کند که در حال حاضر به طور فعال توسط VM استفاده می شود.
در این خصوص به دو نکته باید توجه داشته باشید:
در طول فرآیند sampling مقدار memory page های touch شده صرف نظر از منحصر به فرد بودن یا نبودن آنها و دسترسی به آنها در دوره sampling قبلی است. بنابراین، اگر حافظه active یک VM برای 10 دوره sampling، 1 گیگابایت باقی بماند، به این معنی است که VM شما ممکن است بین 1 گیگابایت تا 10 گیگابایت رم دسترسی داشته باشد، حتی اگر vCenter یک خط مستقیم را روی 1 گیگابایت نشان دهد.
این واقعیت که متریک به دنبال page هایی است که Touch شده اند به این معنی است که لزوماً آنچه را که در سیستم عامل مهمان می گذرد منعکس نمی کند. یک مثال واضح، پایگاه داده SQL است که بخشی از داده های خود را در RAM ذخیره می کند. DB ممکن است 20 گیگابایت را در حافظه رم ذخیره کند، اما در طول یک دوره sampling، فقط به 2 گیگابایت دسترسی داشته باشید، مقدار مموری Active ماشین مجازی 2 گیگابایت خواهد بود، اما اگر در ویندوز نگاه کنید، 22 گیگابایت رم استفاده شده را مشاهده خواهید کرد.

این متریک در ابتدا برای DRS ایجاد شد تا از مصرف منابع بصورت real-time را بدست آورد تا به توزیع بار در هاست ها کمک کند. به این دلایل، درک این نکته مهم است که این متریک نباید برای برنامه ریزی ظرفیت یا مانیتور بر میزان استفاده از مموری سیستم عامل مهمان استفاده شود.
به عنوان یک نکته، ویژگی معرفی شده در 6.5 که به شما امکان می دهد DRS را مجبور کنید از consumed memory به جای حافظه active استفاده کند. این واقعاً یک ویژگی عالی است، به خصوص برای مشتریانی که overcommit memory روی هاست ندارند.

Overhead

حافظه Overhead مقدار حافظه ماشین استفاده شده توسط VMkernel برای اجرای ماشین مجازی را محاسبه می کند. اندازه آن به تعداد virtual CPU ها و حافظه پیکربندی شده برای سیستم عامل مهمان بستگی دارد. یک VM برای اینکه بتواند کار کند به مقدار مشخصی مموری نیاز دارد که به عنوان حافظه overhead شناخته می شود.
می‌توانید این requirement ها را در تصویر زیر مشاهده کنید، اما توجه داشته باشید که همه سناریوها را پوشش نمی‌دهد، فقط رایج‌ترین آنها را پوشش می‌دهد.

Shared

در خصوص Transparent Page Sharing کمی بالاتر صحبت کردیم و ضمن اینکه به لینک مقاله Transparent Page Sharing یا TPS هم که بالاتر آن را قرار دادیم، می توانید مراجعه کنید. متریک shared memory میزان host memory page را که توسط دو یا چند VM به اشتراک گذاشته شده اند را نشان می دهد. اگر یک VM یک Memory Page را درخواست کند که قبلاً VM دیگری به آن دسترسی پیدا کرده است، هاست، Page جدیدی ایجاد نمی کند بلکه Page موجود را به ماشین مجازی Map می کند.(نوعی memory deduplication آن را در نظر بگیرید).
Esxi با فعالیت در پس زمینه اسکن هایی را در فواصل زمانی انجام می دهد و مشخص می‌کند کدام صفحات را می‌توان به اشتراک گذاشت. هرچه Workload مشابه و ثابت بیشتری داشته باشید، به مرور زمان به memory sharing شما بیشتر می شود. این فواصل را می توان با تنظیمات پیشرفته Mem.ShareScanTime و Mem.ShareScanGHz کنترل کرد. برای شناسایی صفحات مشابه، ESXi از هر page ای که در جدول هش ذخیره می کند، یک عدد ایجاد می کند. هنگامی که یک page درخواست شده توسط VM یک هش ایجاد کند که از قبل در جدول وجود دارد، VM به آدرس مربوطه در مموری memory می شود.

Ballooned

حال می خواهیم به تکنیک memory reclamation یا بازپس گیری مموری اشاره کنیم. پیشنهادم این است که حتما مقاله لینک زیر را هم ببینید.


VMware ballooning ویژگی ای است که از درایور بالون (vmmemctl) موجود در VMware tools نصب شده در سیستم عامل مهمان برای آزاد کردن حافظه استفاده می کند تا در صورت کمبود رم برای هاست، آن را به هاست بازگرداند. توجه داشته باشید که اگر VMware tools نصب شده در مهمان اجرا نباشد یا نصب نشده باشد، ballooning روی vm نخواهید داشت.


به منظور وادار کردن مهمان به آزاد کردن memory page، درایور balloon با افزایش فشار مموری بر روی سیستم عامل (Inflating) یک سناریوی درخواست مموری را در مهمان شبیه سازی می کند، که باعث می شود از روش های reclamation خود استفاده کند و page کم ارزش را منتشر کند. مجددا پیشنهاد می کنم که به لینک فوق سری بزنید چرا که در آن به طور کامل در این خصوص صحبت شده است.
و اگر منابع واقعاً محدود باشند، سیستم عامل مهمان را مجبور می کند تا page را با دیسک مجازی خود swap کند. خود vm تصمیم می گیرد که کدام صفحات را swap کند(این page های swap شده در فایلی به نام vswp قرار می گیرد که در دیتااستور vm است). هنگامی که reclamation انجام شد، درایور balloon استاپ می شود و page گرفته شده را در اختیار هاست قرار می دهد(deflate).
با تنظیم پیشرفته sched.mem.maxmemctl می توان مقدار حافظه ای را که درایور balloon می تواند بازپس گیری کند را محدود کرد.

Compressed

Memory compression یکی دیگر از تکنیک‌های reclamation است که برای تطبیق با overcommitment استفاده می‌شود، سعی می‌کند memory page را فشرده کرده و در بخش کوچکی از مموری VM ذخیره کند. این امکان دسترسی بسیار سریع‌تری نسبت به swapping در صورت نیاز به page توسط VM پس از compression را فراهم می‌کند. اگر page های swap شده را بتوان تا ۲ کیلوبایت یا کوچکتر فشرده کرد، در compression cache ماشین مجازی ذخیره می شود و ظرفیت مموری هاست افزایش می یابد.


با این حال، اگر page را نتوان فشرده کرد، به روی دیسک swap می شود. اندازه پیش‌فرض cache مورد استفاده برای ذخیره page های فشرده، 10 درصد فضای حافظه VM است، اما می‌توان آن را با تنظیمات پیشرفته Mem.MemZipMaxPct (بین 5 تا 100 درصد) تغییر داد.

Swapped

Swap حافظه زمانی رخ می دهد که واقعا اوضاع به جاهای باریک کشیده شده باشد و به قولی اوضاع بیخ پیدا کرده باشد. Swap اصلا اتفاق خوبی نیست. این آخرین راه حل از نظر مکانیسم های reclamation است. زمانی که TPS، بالون کردن و فشرده سازی نمی توانند حافظه بیشتری را آزاد کنند، از Swap استفاده می شود. این همان چیزی است که بیشترین تأثیر را روی performance خواهد داشت.
ما در قسمت بالون کردن در مورد Swap صحبت کردیم و گفتیم که در این حالت، Swap توسط سیستم عامل مهمان که در داخل VM اجرا می شود، صورت می گیرد. یعنی سیستم عامل مهمان از بهترین page ها برای Swap به خوبی اطلاع دارد. این page ها به دیسک مجازی Swap خواهند شد و با این اتفاق شاهد افتا فاحش Performance خواهید شد، این نوع swap در monitoring نشان داده نمی شود زیرا در داخل مهمان انجام می شود.
تفاوت با متریک swap در این واقعیت است که وقتی بالون کردن و فشرده سازی کار خود را انجام دادند و دیگر حافظه ای برای reclaim وجود نداشت، ESXi شروع به گرفتن page ها از حافظه VM و قرار دادن آنها به دیسک در فایل swap خود می کند. وقتی این اتفاق رخ دهد esxi نمی تواند تشخیص دهد که کدام page ها برای swap مناسب هستند. این را به مثابه یک بازی دارت با چشم بسته در نظر بگیرید.


توجه داشته باشید که فایل swap به طور پیش‌فرض با ماشین مجازی ذخیره می‌شود، اما می‌توانید مکانی را روی یک حافظه با performance بهتر مانند یک ذخیره‌سازی اطلاعاتی با پشتیبانی از SSD تعیین کنید تا در صورت کمبود حافظه سیستم‌تان، کمی افت performance ناشی از Swapping جبران شود ولی در هر صورت افت performance محسوس خواهد بود.
توجه داشته باشید که دو نوع swapping هم وجود دارد که این دو هم بسیار مهم هستند:

SwapIn

SwapIn به مقدار swap شده به مموری از دیسک اشاره دارد. مقدار داده ای است که از زمان روشن شدن ماشین مجازی از فایل swap در مموری هاست خوانده شده است. بنابراین اگر VM در گذشته به دلیل کمبود حافظه که دیگر وجود ندارد swap شده باشد، به آرامی شاهد افزایش SwapIn خواهید بود، زیرا VM به page های swap شده که به RAM منتقل می شوند دسترسی پیدا می کند.

SwapOut

Swapping out مقداری اشاره می کند که VMkernel از مموری ماشین روی فایل swap ماشین مجازی نوشته است. همانطور که قبلا گفته شد این با guest OS swapping متفاوت است.