در این مقاله در مورد شمارنده های عملکرد حافظه با دسترسی تصادفی (RAM) در vSphere صحبت خواهیم کرد.
به نظر می رسد که با حافظه همه چیز واضح تر از پردازنده است: اگر یک VM مشکلات عملکردی داشته باشد، سخت است که متوجه آنها نشوید. اما اگر ظاهر شوند، مقابله با آنها بسیار دشوارتر است. اما اول از همه.
کمی تئوری
رم ماشین های مجازی از حافظه سروری که ماشین های مجازی روی آن کار می کنند گرفته می شود. کاملا واضحه :). اگر رم سرور برای همه کافی نیست، ESXi شروع به استفاده از تکنیک های احیای حافظه برای بهینه سازی مصرف رم می کند. در غیر این صورت، سیستم عامل VM با خطاهای دسترسی به RAM از کار می افتد.
اینکه کدام تکنیک برای استفاده از ESXi بسته به بار رم تصمیم می گیرد:
وضعیت حافظه
مرز
فعالیت
زیاد
400% MinFree
پس از رسیدن به حد بالا، صفحات حافظه بزرگ به صفحات کوچک تقسیم می شوند (TPS در حالت استاندارد کار می کند).
واضح
100% MinFree
صفحات حافظه بزرگ به صفحات کوچک تقسیم می شوند، TPS مجبور به کار می شود.
نرم
64% MinFree
TPS + بالون
سخت
32% MinFree
TPS + فشرده سازی + تعویض
کم
16% MinFree
فشرده سازی + تعویض + مسدود کردن
minFree رم مورد نیاز برای کار کردن هایپروایزر است.
قبل از ESXi 4.1، minFree به طور پیش فرض ثابت شده بود - 6٪ از RAM سرور (درصد را می توان از طریق گزینه Mem.MinFreePct در ESXi تغییر داد). در نسخه های بعدی به دلیل افزایش حجم حافظه در سرورها، minFree بر اساس میزان حافظه میزبان شروع به محاسبه شد و نه به صورت درصد ثابت.
مقدار minFree (پیش فرض) به صورت زیر محاسبه می شود:
درصد حافظه ذخیره شده برای minFree
محدوده حافظه
6%
0-4 گیگابایت
4%
4-12 گیگابایت
2%
12-28 گیگابایت
1%
حافظه باقی مانده
به عنوان مثال، برای سروری با 128 گیگابایت رم، مقدار MinFree خواهد بود:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 مگابایت = 1,88 گیگابایت
مقدار واقعی ممکن است چند صد مگابایت متفاوت باشد، این به سرور و RAM بستگی دارد.
درصد حافظه ذخیره شده برای minFree
محدوده حافظه
ارزش برای 128 گیگابایت
6%
0-4 گیگابایت
245,76 مگابایت
4%
4-12 گیگابایت
327,68 مگابایت
2%
12-28 گیگابایت
327,68 مگابایت
1%
حافظه باقیمانده (100 گیگابایت)
1024 مگابایت
معمولاً برای غرفه های تولیدی فقط حالت High را می توان نرمال در نظر گرفت. برای میزهای آزمایش و توسعه، حالت های Clear/Soft ممکن است قابل قبول باشد. اگر رم روی هاست کمتر از 64 درصد MinFree باشد، ماشین های مجازی که روی آن کار می کنند قطعاً مشکلات عملکردی دارند.
در هر حالت، تکنیک‌های خاصی برای احیای حافظه اعمال می‌شود که با TPS شروع می‌شود که عملاً بر عملکرد ماشین مجازی تأثیر نمی‌گذارد و با Swapping خاتمه می‌یابد. در مورد آنها بیشتر به شما خواهم گفت.
به اشتراک گذاری صفحه شفاف (TPS). TPS، به طور کلی، حذف مجدد صفحات حافظه ماشین مجازی در سرور است.
ESXi با شمارش و مقایسه مجموع هش صفحات به دنبال صفحات یکسان رم ماشین مجازی می گردد و صفحات تکراری را حذف می کند و آنها را با پیوندهایی به همان صفحه در حافظه فیزیکی سرور جایگزین می کند. در نتیجه، مصرف حافظه فیزیکی کاهش می‌یابد و می‌توان با کاهش کم یا بدون کاهش عملکرد، مقداری بیش از حد اشتراک حافظه را به دست آورد.
این مکانیزم فقط برای صفحات حافظه 4 کیلوبایتی (صفحات کوچک) کار می کند. هایپروایزر حتی سعی نمی کند صفحات 2 مگابایتی (صفحه های بزرگ) را حذف کند: شانس یافتن صفحات یکسان با این اندازه زیاد نیست.
به طور پیش فرض، ESXi حافظه را به صفحات بزرگ اختصاص می دهد. شکستن صفحات بزرگ به صفحات کوچک با رسیدن به آستانه حالت بالا شروع می شود و با رسیدن به حالت پاک کردن اجباری می شود (جدول حالت هایپروایزر را ببینید).
اگر می خواهید TPS بدون انتظار برای پر شدن رم میزبان شروع به کار کند، در Advanced Options ESXi باید مقدار را تنظیم کنید. “Mem.AllocGuestLargePage” به 0 (پیش فرض 1). سپس تخصیص صفحات حافظه بزرگ برای ماشین های مجازی غیرفعال می شود.
از دسامبر 2014، در تمام نسخه‌های ESXi، TPS بین ماشین‌های مجازی به‌طور پیش‌فرض غیرفعال شده است، زیرا آسیب‌پذیری پیدا شد که از نظر تئوری دسترسی از یک ماشین مجازی به رم ماشین مجازی دیگر را امکان‌پذیر می‌کند. جزئیات اینجا. من با اطلاعاتی در مورد اجرای عملی بهره برداری از آسیب پذیری TPS مواجه نشده ام.
سیاست TPS از طریق گزینه پیشرفته کنترل می شود "Mem.ShareForceSalting" در ESXi:
0 - Inter-VM TPS. TPS برای صفحات ماشین های مجازی مختلف کار می کند.
1 - TPS برای VM با همان مقدار "sched.mem.pshare.salt" در VMX.
2 (پیش فرض) - Intra-VM TPS. TPS برای صفحات داخل VM کار می کند.
قطعاً خاموش کردن صفحات بزرگ و روشن کردن Inter-VM TPS در میزهای تست منطقی است. همچنین می توان از آن برای استندهایی با تعداد زیادی از همان نوع ماشین مجازی استفاده کرد. به عنوان مثال، در استندهای دارای VDI، صرفه جویی در حافظه فیزیکی می تواند به ده ها درصد برسد.
بادکنک زدن حافظه بالون زدن دیگر تکنیک بی ضرر و شفافی برای سیستم عامل VM به عنوان TPS نیست. اما با استفاده مناسب می توانید با Balloning زندگی و حتی کار کنید.
همراه با Vmware Tools، درایور خاصی به نام درایور بالون (با نام مستعار vmmemctl) روی ماشین مجازی نصب شده است. هنگامی که هایپروایزر شروع به اتمام حافظه فیزیکی می کند و وارد حالت Soft می شود، ESXi از VM می خواهد تا RAM استفاده نشده را از طریق این درایور بالون بازیابی کند. درایور به نوبه خود در سطح سیستم عامل کار می کند و از آن حافظه رایگان درخواست می کند. هایپروایزر می بیند که درایور بالون کدام صفحات حافظه فیزیکی را اشغال کرده است، حافظه را از ماشین مجازی می گیرد و به هاست برمی گرداند. هیچ مشکلی در عملکرد سیستم عامل وجود ندارد، زیرا در سطح سیستم عامل، حافظه توسط درایور بالون اشغال می شود. به طور پیش فرض Balloon Driver می تواند تا 65 درصد از حافظه VM را اشغال کند.
اگر VMware Tools روی VM نصب نشده باشد یا Balloning غیرفعال باشد (توصیه نمی کنم، اما وجود دارد :)، هایپروایزر بلافاصله به تکنیک های حذف حافظه دقیق تر تغییر می کند. نتیجه گیری: مطمئن شوید که VMware Tools روی VM است.
عملکرد بالون درایور را می توان از طریق سیستم عامل از طریق ابزارهای VMware بررسی کرد.
فشرده سازی حافظه این تکنیک زمانی استفاده می شود که ESXi به حالت Hard برسد. همانطور که از نام آن پیداست، ESXi سعی می کند یک صفحه 4 کیلوبایتی از RAM را به 2 کیلوبایت کوچک کند و در نتیجه فضایی را در حافظه فیزیکی سرور آزاد کند. این تکنیک زمان دسترسی به محتویات صفحات رم VM را به میزان قابل توجهی افزایش می دهد، زیرا صفحه باید ابتدا از حالت فشرده خارج شود. گاهی اوقات همه صفحات را نمی توان فشرده کرد و خود این فرآیند کمی طول می کشد. بنابراین، این تکنیک در عمل چندان موثر نیست.
تعویض حافظه پس از یک مرحله فشرده سازی حافظه کوتاه، ESXi تقریباً به ناچار (اگر VM ها برای میزبان های دیگر رها نشده باشند یا خاموش نشده باشند) به Swapping تغییر می کند. و اگر حافظه بسیار کمی باقی مانده باشد (Low State) ، هایپروایزر نیز تخصیص صفحات حافظه به VM را متوقف می کند که می تواند باعث ایجاد مشکل در سیستم عامل مهمان VM شود.
در اینجا نحوه عملکرد Swapping آمده است. هنگامی که یک ماشین مجازی را روشن می کنید، یک فایل با پسوند vswp. برای آن ایجاد می شود. اندازه آن با رم ذخیره نشده ماشین مجازی برابر است: این تفاوت بین حافظه پیکربندی شده و ذخیره شده است. هنگامی که Swapping در حال اجرا است، ESXi صفحات حافظه ماشین مجازی را در این فایل تخلیه می کند و به جای حافظه فیزیکی سرور با آن شروع به کار می کند. البته، چنین حافظه «عملیاتی» چندین مرتبه کندتر از حافظه واقعی است، حتی اگر .vswp در ذخیره سازی سریع قرار داشته باشد.
برخلاف Balloning، زمانی که صفحات بلااستفاده از VM گرفته می‌شوند، با Swapping، صفحاتی که به طور فعال توسط سیستم عامل یا برنامه‌های داخل ماشین مجازی استفاده می‌شوند، می‌توانند به دیسک منتقل شوند. در نتیجه، عملکرد ماشین مجازی تا حد انجماد کاهش می یابد. VM به طور رسمی کار می کند و حداقل می توان آن را به درستی از سیستم عامل غیرفعال کرد. اگر صبور هستید 😉
اگر ماشین های مجازی به Swap رفتند، این یک وضعیت غیرعادی است که در صورت امکان بهتر است از آن اجتناب کنید.
شمارنده های کلیدی عملکرد حافظه VM
بنابراین به اصل مطلب رسیدیم. برای نظارت بر وضعیت حافظه در VM، شمارنده های زیر وجود دارد:
فعال - مقدار RAM (KB) را نشان می دهد که VM در دوره اندازه گیری قبلی به آن دسترسی داشته است.
استفاده - مانند Active، اما به عنوان درصدی از RAM پیکربندی شده VM. با استفاده از فرمول زیر محاسبه می شود: اندازه حافظه پیکربندی شده ماشین مجازی فعال ÷.
استفاده زیاد و Active به ترتیب همیشه نشانگر مشکلات عملکرد VM نیستند. اگر VM به طور تهاجمی از حافظه استفاده می کند (حداقل به آن دسترسی پیدا می کند)، این بدان معنا نیست که حافظه کافی وجود ندارد. بلکه فرصتی است برای دیدن آنچه در سیستم عامل اتفاق می افتد.
یک هشدار استاندارد استفاده از حافظه برای ماشین های مجازی وجود دارد:
به اشتراک گذاشته شده - مقدار رم VM که با استفاده از TPS (داخل ماشین مجازی یا بین ماشین های مجازی) کپی شده است.
اعطا - مقدار حافظه میزبان فیزیکی (KB) که به VM داده شده است. شامل اشتراک گذاری شده است.
مصرف شده (Granted - Shared) - مقدار حافظه فیزیکی (KB) که VM از میزبان مصرف می کند. اشتراک گذاری را شامل نمی شود.
اگر بخشی از حافظه VM نه از حافظه فیزیکی هاست، بلکه از فایل swap داده شود و یا از طریق درایور Balloon از VM گرفته شود، این مقدار در Granted and Consumed لحاظ نمی شود.
مقادیر اعطایی و مصرفی بالا کاملاً طبیعی هستند. سیستم عامل به تدریج حافظه را از هایپروایزر می گیرد و آن را پس نمی دهد. با گذشت زمان، در یک VM فعال در حال اجرا، مقادیر این شمارنده ها به مقدار حافظه پیکربندی شده نزدیک می شوند و در آنجا باقی می مانند.
صفر - مقدار رم VM (KB) که حاوی صفر است. چنین حافظه ای توسط هایپروایزر رایگان در نظر گرفته می شود و می تواند به ماشین های مجازی دیگر داده شود. پس از اینکه سیستم عامل مهمان چیزی در حافظه صفر نوشت، به Consumed می رود و برنمی گردد.
سربار رزرو شده - مقدار VM RAM، (KB) که توسط هایپروایزر برای عملیات VM رزرو شده است. این مقدار کمی است، اما باید در هاست موجود باشد، در غیر این صورت VM راه اندازی نمی شود.
بالون - مقدار RAM (KB) ضبط شده از VM با استفاده از درایور بالون.
فشرده - مقدار RAM (KB) که فشرده شده است.
تعویض شده - مقدار RAM (KB) که به دلیل کمبود حافظه فیزیکی روی سرور، به دیسک منتقل شده است.
شمارنده های بالون و سایر تکنیک های احیای حافظه صفر هستند.
این نمودار با شمارنده های حافظه برای یک ماشین مجازی معمولی با 150 گیگابایت رم به نظر می رسد.
در نمودار زیر، VM مشکلات آشکاری دارد. در زیر نمودار می بینید که برای این ماشین مجازی از تمامی تکنیک های توصیف شده برای کار با رم استفاده شده است. بالون برای این VM بسیار بزرگتر از Consumed است. در واقع، VM بیشتر مرده است تا زنده.
ESXTOP
همانند CPU، اگر بخواهیم به سرعت وضعیت هاست و همچنین دینامیک آن را با فاصله حداکثر 2 ثانیه ارزیابی کنیم، باید از ESXTOP استفاده کنیم.
صفحه ESXTOP توسط Memory با کلید "m" فراخوانی می شود و به این شکل است (فیلدهای B، D، H، J، K، L، O انتخاب شده اند):
پارامترهای زیر برای ما جالب خواهد بود:
Mem overcommit میانگین - میانگین مقدار اشتراک بیش از حد حافظه در میزبان برای 1، 5 و 15 دقیقه. اگر بالای صفر باشد، این فرصتی است برای دیدن آنچه اتفاق می افتد، اما همیشه نشانگر مشکلات نیست.
در خطوط PMEM/MB и VMKMEM/MB - اطلاعات مربوط به حافظه فیزیکی سرور و حافظه موجود در VMkernel. از موارد جالب اینجا می توانید مقدار minfree (در مگابایت)، وضعیت هاست در حافظه (در مورد ما بالا) را مشاهده کنید.
در صف NUMA/MB می توانید توزیع RAM را توسط گره های NUMA (سوکت) مشاهده کنید. در این مثال توزیع ناهموار است که در اصل خیلی خوب نیست.
در زیر آمار کلی سرور در مورد تکنیک های احیای حافظه آورده شده است:
PSHARE/MB آمار TPS هستند.
SWAP/MB - آمار استفاده از مبادله
ZIP/MB - آمار فشرده سازی صفحه حافظه؛
MEMCTL/MB - آمار استفاده از درایور بالون.
برای ماشین های مجازی شخصی، ممکن است به اطلاعات زیر علاقه مند باشیم. نام های VM را پنهان کردم تا مخاطب را سردرگم نکنم :). اگر متریک ESXTOP شبیه شمارنده در vSphere باشد، شمارنده مربوطه را می‌دهم.
MEMSZ - مقدار حافظه پیکربندی شده روی ماشین مجازی (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + دست نخورده.
اعطا کردن - به MB اعطا شد.
TCHD - فعال در مگابایت
MCTL؟ - آیا Balloon Driver روی VM نصب شده است یا خیر.
MCTLSZ - بالون به مگابایت.
MCTLGT - مقدار RAM (MB) که ESXi می خواهد از طریق درایور بالون (Memctl Target) از VM بگیرد.
MCTLMAX - حداکثر مقدار RAM (MB) که ESXi می تواند از VM از طریق درایور بالون بگیرد.
SWCUR - مقدار فعلی RAM (MB) که از فایل Swap به VM اختصاص داده شده است.
S.W.G.T. - مقدار RAM (MB) که ESXi می خواهد از فایل Swap (Swap Target) به VM بدهد.
همچنین از طریق ESXTOP می توانید اطلاعات دقیق تری در مورد توپولوژی NUMA ماشین مجازی مشاهده کنید. برای انجام این کار، فیلدهای D، G را انتخاب کنید:
کم اهمیت – گره های NUMA که ماشین مجازی روی آن ها قرار دارد. در اینجا می توانید بلافاصله متوجه vm گسترده ای شوید که در یک گره NUMA مناسب نیست.
NRMEM - VM چند مگابایت حافظه از گره NUMA راه دور می گیرد.
NLMEM - VM چند مگابایت حافظه از گره NUMA محلی می گیرد.
N%L - درصد حافظه VM در گره NUMA محلی (اگر کمتر از 80٪ باشد، ممکن است مشکلات عملکردی رخ دهد).
حافظه روی هایپروایزر
اگر شمارنده های CPU برای هایپروایزر معمولاً مورد توجه خاصی نیستند، در این صورت وضعیت با حافظه برعکس می شود. استفاده از حافظه زیاد در ماشین مجازی همیشه نشان دهنده مشکل عملکرد نیست، اما استفاده از حافظه بالا در یک هایپروایزر تکنیک های مدیریت حافظه را راه اندازی می کند و باعث مشکلات عملکرد در ماشین مجازی می شود. آلارم‌های استفاده از حافظه میزبان باید نظارت شوند تا از ورود VM به Swap جلوگیری شود.
تعویض کنید
اگر یک VM در Swap باشد، عملکرد آن بسیار کاهش می یابد. پس از ظاهر شدن رم رایگان روی هاست، آثار بالن و فشرده سازی به سرعت ناپدید می شوند، اما ماشین مجازی عجله ای برای بازگشت از Swap به رم سرور ندارد.
قبل از ESXi 6.0، تنها راه مطمئن و سریع برای خارج کردن VM از Swap راه‌اندازی مجدد بود (به‌طور دقیق‌تر، کانتینر را خاموش/روشن کنید). با شروع با ESXi 6.0، اگرچه کاملاً رسمی نیست، یک روش کارآمد و قابل اعتماد برای حذف VM از Swap ظاهر شده است. در یکی از کنفرانس ها، من توانستم با یکی از مهندسان VMware که مسئول CPU Scheduler بود صحبت کنم. او تأیید کرد که این روش کاملاً مؤثر و ایمن است. طبق تجربه ما، هیچ مشکلی با آن وجود نداشت.
دستورات واقعی برای حذف VM از Swap دانکن اپینگ من توضیح مفصل را تکرار نمی کنم، فقط یک مثال از کاربرد آن را ذکر می کنم. همانطور که در اسکرین شات مشاهده می کنید، مدتی پس از اجرای دستورات مشخص شده، Swap روی ماشین مجازی ناپدید می شود.
نکات مدیریت حافظه ESXi
در نهایت، در اینجا چند نکته وجود دارد که به شما کمک می کند از مشکلات عملکرد VM به دلیل RAM جلوگیری کنید:
- از اشتراک بیش از حد حافظه در خوشه های مولد خودداری کنید. مطلوب است که همیشه 20 تا 30 درصد حافظه آزاد در خوشه وجود داشته باشد تا DRS (و مدیر) فضایی برای مانور داشته باشند و ماشین های مجازی در حین مهاجرت وارد Swap نشوند. همچنین، حاشیه تحمل خطا را فراموش نکنید. زمانی که یک سرور از کار می افتد و VM با استفاده از HA راه اندازی مجدد می شود، برخی از ماشین ها نیز به Swap می روند، ناخوشایند است.
- در زیرساخت های بسیار یکپارچه، سعی کنید VM هایی با بیش از نیمی از حافظه میزبان ایجاد نکنید. این دوباره به DRS کمک می کند تا ماشین های مجازی را بدون هیچ مشکلی در سراسر سرورهای کلاستر توزیع کند. این قانون، البته، جهانی نیست :).
- مراقب هشدار استفاده از حافظه میزبان باشید.
- فراموش نکنید که VMware Tools را روی ماشین مجازی نصب کنید و Balloning را خاموش نکنید.
- فعال کردن Inter-VM TPS و غیرفعال کردن صفحات بزرگ در VDI و محیط های آزمایشی را در نظر بگیرید.
- اگر VM با مشکلات عملکردی مواجه است، بررسی کنید که آیا از حافظه یک گره NUMA راه دور استفاده می کند یا خیر.
- هر چه سریعتر VM خود را از Swap خارج کنید! از جمله، اگر VM در Swap باشد، به دلایل واضح، سیستم ذخیره سازی آسیب می بیند.
این همه چیز برای من در مورد RAM است. در زیر یک مقاله مرتبط برای کسانی که می خواهند جزئیات را بررسی کنند، آورده شده است. مقاله بعدی به storadzh اختصاص داده خواهد شد.
لینک های مفید
منبع: www.habr.com