اگر زیرساخت مجازی مبتنی بر VMware vSphere (یا هر پشته فناوری دیگر) را مدیریت میکنید، احتمالاً اغلب شکایتهایی از کاربران میشنوید: «ماشین مجازی کند است!». در این سری از مقالات، معیارهای عملکرد را تجزیه و تحلیل خواهم کرد و به شما خواهم گفت که چه چیزی و چرا "آهسته می شود" و چگونه مطمئن شوید که "آهسته" نمی شود.
من جنبه های زیر عملکرد ماشین مجازی را در نظر خواهم گرفت:
- CPU ،
- رم،
- دیسک،
- شبکه.
من با CPU شروع می کنم.
برای تجزیه و تحلیل عملکرد ما نیاز داریم:
- شمارنده های عملکرد vCenter - شمارشگرهای عملکرد، که نمودارهای آنها را می توان از طریق vSphere Client مشاهده کرد. اطلاعات این شمارنده ها در هر نسخه از کلاینت در دسترس است (کلاینت "ضخیم" در C#، سرویس گیرنده وب در Flex، و سرویس گیرنده وب در HTML5). در این مقاله ها از اسکرین شات های کلاینت C# استفاده می کنیم، فقط به این دلیل که در مینیاتوری بهتر به نظر می رسند :)
- ESXTOP ابزاری است که از خط فرمان ESXi اجرا می شود. با کمک آن می توانید مقادیر شمارنده های عملکرد را در زمان واقعی دریافت کنید یا این مقادیر را برای یک دوره معین در یک فایل .csv برای تجزیه و تحلیل بیشتر آپلود کنید. در مرحله بعد، در مورد این ابزار بیشتر به شما خواهم گفت و پیوندهای مفیدی به اسناد و مقالات در مورد این موضوع ارائه خواهم کرد.
کمی تئوری
در ESXi، یک فرآیند جداگانه مسئول عملکرد هر vCPU (هسته ماشین مجازی) است - جهان در اصطلاح VMware. فرآیندهای خدماتی نیز وجود دارد، اما از نقطه نظر تجزیه و تحلیل عملکرد VM، آنها کمتر جالب هستند.
یک فرآیند در ESXi می تواند در یکی از چهار حالت باشد:
- دویدن این فرآیند کار مفیدی انجام می دهد.
- صبر کنيد - فرآیند هیچ کاری انجام نمی دهد (بیکار) یا منتظر ورودی / خروجی است.
- کاستاپ - حالتی که در ماشین های مجازی چند هسته ای رخ می دهد. زمانی اتفاق میافتد که زمانبندی CPU Hypervisor (ESXi CPU Scheduler) نمیتواند همه هستههای ماشین مجازی فعال را برای اجرا بر روی هستههای فیزیکی سرور به طور همزمان برنامهریزی کند. در دنیای فیزیکی، تمام هستههای پردازنده به صورت موازی کار میکنند، سیستمعامل مهمان در داخل ماشین مجازی انتظار رفتار مشابهی را دارد، بنابراین هایپروایزر باید هستههای VM را کاهش دهد، که این فرصت را دارند تا چرخه را سریعتر به پایان برسانند. در نسخههای مدرن ESXi، زمانبندی CPU از مکانیزمی به نام همزمانبندی آرام استفاده میکند: هایپروایزر شکاف بین «سریعترین» و «کندترین» هسته ماشین مجازی (کول) را محاسبه میکند. اگر شکاف از یک آستانه خاص فراتر رود، هسته "سریع" وارد حالت هزینه می شود. اگر هسته های VM زمان زیادی را در این حالت بگذرانند، می تواند باعث مشکلات عملکرد شود.
- آماده تحویل – فرآیند زمانی وارد این حالت می شود که هایپروایزر نتواند منابعی را برای اجرای خود اختصاص دهد. مقادیر آماده بالا می تواند باعث مشکلات عملکرد VM شود.
شمارنده های اصلی عملکرد CPU VM
میزان استفاده از پردازنده، ٪. درصد استفاده از CPU را برای دوره مشخص شده نشان می دهد.
چگونه تحلیل کنیم؟ اگر VM به طور مداوم از CPU در 90٪ استفاده کند یا حداکثر تا 100٪ وجود داشته باشد، مشکل داریم. مشکلات را می توان نه تنها در عملکرد "آهسته" برنامه در داخل VM، بلکه در عدم دسترسی به VM از طریق شبکه بیان کرد. اگر سیستم مانیتورینگ نشان میدهد که VM به صورت دورهای از کار میافتد، به پیکهای نمودار استفاده از CPU توجه کنید.
یک هشدار استاندارد وجود دارد که بار CPU ماشین مجازی را نشان می دهد:
چه کاری انجام دهید؟ اگر VM دائماً مقیاس استفاده از CPU را کاهش می دهد، می توانید به افزایش تعداد vCPU ها فکر کنید (متاسفانه این همیشه کمکی نمی کند) یا انتقال ماشین مجازی به سروری با پردازنده های کارآمدتر.
استفاده از CPU در مگاهرتز
در نمودارهای vCenter، Usage in % فقط برای کل ماشین مجازی قابل مشاهده است، هیچ نموداری برای هستههای جداگانه وجود ندارد (در Esxtop مقادیر بر حسب درصد برای هستهها وجود دارد). برای هر هسته، می توانید Usage را در مگاهرتز ببینید.
چگونه تحلیل کنیم؟ این اتفاق می افتد که یک برنامه برای یک معماری چند هسته ای بهینه نشده است: فقط از یک هسته در 100٪ استفاده می کند و بقیه بدون بارگذاری بیکار هستند. برای مثال، با تنظیمات پیشفرض پشتیبانگیری، MS SQL فرآیند را تنها روی یک هسته شروع میکند. در نتیجه، سرعت پشتیبان گیری نه به دلیل سرعت پایین دیسک ها (این همان چیزی است که کاربر در ابتدا از آن شکایت می کرد) کند می شود، بلکه به این دلیل که پردازنده نمی تواند با آن مقابله کند. مشکل با تغییر پارامترها حل شد: پشتیبان گیری شروع به اجرای موازی در چندین فایل (به ترتیب در چندین فرآیند) کرد.
نمونه ای از بارگذاری ناهموار هسته ها.
همچنین وضعیتی (مانند نمودار بالا) وجود دارد که هسته ها به طور ناهموار بارگذاری می شوند و برخی از آنها پیک های 100٪ دارند. همانطور که با بارگذاری تنها یک هسته، هشدار استفاده از CPU کار نخواهد کرد (در تمام VM است)، اما مشکلات عملکردی وجود خواهد داشت.
چه کاری انجام دهید؟ اگر نرم افزار موجود در ماشین مجازی هسته ها را به طور ناموزون بارگذاری کند (فقط از یک هسته یا بخشی از هسته ها استفاده می کند)، افزایش تعداد آنها بی معنی است. در این صورت بهتر است ماشین مجازی را به سروری با پردازنده های کارآمدتر منتقل کنید.
همچنین می توانید تنظیمات برق را در بایوس سرور بررسی کنید. بسیاری از مدیران حالت High Performance را در BIOS فعال می کنند و در نتیجه فناوری های ذخیره انرژی C-states و P-states را غیرفعال می کنند. پردازندههای مدرن اینتل از فناوری Turbo Boost استفاده میکنند که فرکانس هستههای پردازنده را به قیمت هستههای دیگر افزایش میدهد. اما فقط زمانی کار میکند که فناوریهای صرفهجویی در مصرف انرژی فعال باشند. اگر آنها را غیرفعال کنیم، پردازنده نمیتواند مصرف انرژی هستههایی را که بارگذاری نمیشوند کاهش دهد.
VMware توصیه میکند فناوریهای صرفهجویی در مصرف انرژی را در سرورها غیرفعال نکنید، بلکه حالتهایی را انتخاب کنید که حداکثر مدیریت انرژی را به هایپروایزر میدهند. در عین حال در تنظیمات مصرف برق Hypervisor باید High Performance را انتخاب کنید.
اگر ماشینهای مجازی (یا هستههای ماشین مجازی) جداگانه در زیرساخت خود دارید که به فرکانس CPU افزایش یافته نیاز دارند، پیکربندی صحیح مصرف انرژی میتواند عملکرد آنها را به میزان قابل توجهی بهبود بخشد.
CPU آماده (آمادگی)
اگر هسته VM (vCPU) در حالت آماده باشد، کار مفیدی انجام نمی دهد. این شرایط زمانی رخ میدهد که هایپروایزر هسته فیزیکی رایگانی را پیدا نمیکند که فرآیند vCPU ماشین مجازی را بتوان به آن اختصاص داد.
چگونه تحلیل کنیم؟ به طور معمول، اگر هسته های یک ماشین مجازی بیش از 10٪ مواقع در حالت آماده باشند، متوجه مشکلات عملکرد خواهید شد. به عبارت ساده، بیش از 10 درصد مواقع VM منتظر در دسترس بودن منابع فیزیکی است.
در vCenter می توانید 2 شمارنده مربوط به CPU Ready را مشاهده کنید:
- آمادگی،
- آماده.
مقادیر هر دو شمارنده را می توان هم برای کل VM و هم برای هسته های جداگانه مشاهده کرد.
Readiness مقدار را بلافاصله به صورت درصد نشان می دهد، اما فقط در زمان واقعی (داده های ساعت آخر، فاصله اندازه گیری 20 ثانیه). این شمارنده بهتر است فقط برای پیدا کردن مشکلات در تعقیب داغ استفاده شود.
مقادیر متقابل آماده را می توان در منظر تاریخی نیز مشاهده کرد. این برای ایجاد الگوها و برای تجزیه و تحلیل عمیق تر مشکل مفید است. به عنوان مثال، اگر یک ماشین مجازی در زمان مشخصی شروع به مشکلات عملکرد کند، میتوانید فواصل شناور بودن CPU Ready را با بار کلی سروری که ماشین مجازی در آن کار میکند مقایسه کنید و اقداماتی را برای کاهش بار انجام دهید (در صورت عدم موفقیت DRS).
Ready برخلاف Readiness نه بر حسب درصد، بلکه در میلی ثانیه نشان داده می شود. این یک شمارنده از نوع Sumation است، یعنی نشان می دهد که هسته VM در طول دوره اندازه گیری چقدر زمان در حالت آماده بوده است. با استفاده از یک فرمول ساده می توانید این مقدار را به درصد تبدیل کنید:
(مقدار جمع بندی آماده CPU / (فاصله به روز رسانی پیش فرض نمودار بر حسب ثانیه * 1000)) * 100 = CPU % آماده
به عنوان مثال، برای VM در نمودار زیر، حداکثر مقدار Ready برای کل ماشین مجازی خواهد بود:
هنگام محاسبه مقدار Ready به صورت درصد، باید به دو نکته توجه کنید:
- مقدار Ready در کل VM مجموع Ready در سراسر هسته ها است.
- فاصله اندازه گیری برای Real-time، این 20 ثانیه است، و برای مثال، در نمودارهای روزانه، این 300 ثانیه است.
با عیب یابی فعال، می توان این لحظات ساده را به راحتی از دست داد و زمان ارزشمندی را برای حل مشکلات موجود تلف کرد.
بیایید Ready را بر اساس داده های نمودار زیر محاسبه کنیم. (324474/(20*1000))*100 = 1622% برای کل VM. اگر به هسته ها نگاه کنید چندان ترسناک نیست: 1622/64 = 25٪ در هر هسته. در این مورد، تشخیص بسیار آسان است: مقدار Ready غیر واقعی است. اما اگر ما در مورد 10-20٪ برای کل VM با چندین هسته صحبت کنیم، آنگاه برای هر هسته ممکن است مقدار در محدوده نرمال باشد.
چه کاری انجام دهید؟ مقدار Ready بالا نشان می دهد که سرور منابع پردازنده کافی برای عملکرد عادی ماشین های مجازی را ندارد. در چنین شرایطی، تنها کاهش اشتراک بیش از حد توسط پردازنده (vCPU:pCPU) باقی می ماند. بدیهی است که این امر می تواند با کاهش پارامترهای ماشین های مجازی موجود یا با انتقال بخشی از ماشین مجازی به سرورهای دیگر محقق شود.
توقف مشترک
چگونه تحلیل کنیم؟ این شمارنده نیز دارای نوع Sumation است و به روش Ready به درصد تبدیل می شود:
(مقدار جمعبندی همزمان CPU / (فاصله بهروزرسانی پیشفرض نمودار بر حسب ثانیه * 1000)) * 100 = CPU co-stop %
در اینجا باید به تعداد هسته های هر VM و فاصله اندازه گیری نیز توجه کنید.
در حالت هزینه، هسته کار مفیدی انجام نمی دهد. با اندازه مناسب VM و بارگذاری معمولی سرور، شمارنده co-stop باید نزدیک به صفر باشد.
در این مورد، بار به وضوح غیر طبیعی است :)
چه کاری انجام دهید؟ اگر چندین ماشین مجازی با تعداد هستههای زیاد روی یک Hypervisor در حال اجرا باشند و اشتراک بیش از حد توسط CPU وجود داشته باشد، ممکن است شمارنده co-stop افزایش یابد که منجر به مشکلاتی در عملکرد این ماشینهای مجازی میشود.
همچنین، اگر از رشتهها برای هستههای فعال یک ماشین مجازی روی یک هسته سرور فیزیکی با فعال بودن Hyper-treading استفاده شود، co-stop افزایش مییابد. این وضعیت میتواند رخ دهد، برای مثال، اگر VM هستههای بیشتری نسبت به مقدار فیزیکی آن در سروری که در آن اجرا میشود، داشته باشد، یا اگر تنظیمات "preferHT" برای VM فعال باشد. می توانید در مورد این تنظیم بخوانید.
برای جلوگیری از مشکلات عملکرد ماشین مجازی به دلیل توقف های زیاد، ماشین مجازی را مطابق با توصیه های سازنده برای نرم افزاری که روی آن ماشین مجازی اجرا می شود و قابلیت های سرور فیزیکی که ماشین مجازی در آن اجرا می شود، اندازه کنید.
هسته ها را در رزرو اضافه نکنید، این می تواند باعث مشکلات عملکردی نه تنها برای خود ماشین مجازی، بلکه برای همسایگان آن در سرور نیز شود.
سایر معیارهای مفید CPU
دویدن - چه مدت (ms) در طول دوره اندازه گیری، vCPU در حالت RUN قرار داشت، یعنی در واقع کار مفیدی انجام داد.
آرام - مدت زمان (ms) در طول دوره اندازه گیری vCPU در حالت بیکار بوده است. مقادیر بالای Idle مشکلی نیست، فقط این است که vCPU "کاری برای انجام دادن" نداشت.
صبر کنيد - چه مدت (میلیثانیه) در طول دوره اندازهگیری، vCPU در حالت انتظار بود. از آنجایی که IDLE در این شمارنده گنجانده شده است، مقادیر بالای Wait نیز نشان دهنده مشکل نیست. اما اگر Wait IDLE در هنگام بالا کم باشد، VM منتظر تکمیل عملیات I / O بود و این به نوبه خود ممکن است نشان دهنده مشکل در عملکرد هارد دیسک یا هر دستگاه مجازی VM باشد.
حداکثر محدود است - چه مدت (میلیثانیه) در طول دوره اندازهگیری، به دلیل محدودیت منابع تنظیم شده، vCPU در حالت آماده بود. اگر عملکرد به طور غیرقابل توضیحی پایین است، بررسی مقدار این شمارنده و محدودیت CPU در تنظیمات VM مفید است. ماشینهای مجازی ممکن است در واقع محدودیتهایی داشته باشند که شما از آنها اطلاعی ندارید. به عنوان مثال، این اتفاق زمانی می افتد که یک VM از قالبی که محدودیت CPU روی آن تنظیم شده بود، کلون شده است.
تعویض صبر کنید - چه مدت در طول دوره اندازه گیری vCPU منتظر عملیات با VMkernel Swap بوده است. اگر مقدار این شمارنده بالای صفر باشد، ماشین مجازی قطعاً مشکلات عملکردی دارد. در مقاله مربوط به شمارنده های رم بیشتر در مورد SWAP صحبت خواهیم کرد.
ESXTOP
اگر شمارنده های عملکرد در vCenter برای تجزیه و تحلیل داده های تاریخی خوب هستند، تجزیه و تحلیل آنلاین مشکل در ESXTOP بهتر است. در اینجا، تمام مقادیر به صورت تمام شده ارائه می شوند (نیازی به ترجمه چیزی نیست) و حداقل دوره اندازه گیری 2 ثانیه است.
صفحه ESXTOP در CPU با کلید "c" فراخوانی می شود و به شکل زیر است:
برای راحتی، میتوانید با فشار دادن Shift-V، فقط فرآیندهای ماشین مجازی را رها کنید.
برای مشاهده معیارهای تک تک هسته های ماشین مجازی، "e" را فشار دهید و GID ماشین مجازی مورد نظر خود را تایپ کنید (30919 در تصویر زیر):
من به طور خلاصه ستون هایی را که به طور پیش فرض ارائه شده اند مرور می کنم. ستون های اضافی را می توان با فشار دادن "f" اضافه کرد.
NWLD (تعداد دنیاها) تعداد فرآیندهای گروه است. برای گسترش گروه و مشاهده معیارهای هر فرآیند (به عنوان مثال، برای هر هسته یک ماشین مجازی چند هسته ای)، "e" را فشار دهید. اگر بیش از یک فرآیند در یک گروه وجود داشته باشد، آنگاه معیارهای گروه برابر با مجموع معیارهای فرآیندهای فردی است.
٪استفاده شده - یک فرآیند یا گروهی از فرآیندها از چند چرخه CPU سرور استفاده می کند.
٪اجرا کن - چه مدت در طول دوره اندازه گیری فرآیند در حالت RUN بوده است، یعنی. کار مفیدی انجام داد تفاوت با %USED در این است که بیش رشتهای، مقیاسبندی فرکانس و زمان صرف شده برای وظایف سیستم (%SYS) را در نظر نمیگیرد.
%SYS - زمان صرف شده برای وظایف سیستم، به عنوان مثال: پردازش وقفه، I/O، شبکه و غیره. اگر VM مقدار زیادی I/O داشته باشد، مقدار می تواند زیاد باشد.
%OVRLP - هسته فیزیکی که فرآیند VM روی آن اجرا می شود چقدر برای وظایف سایر فرآیندها صرف شده است.
این معیارها به صورت زیر به یکدیگر مربوط می شوند:
%USED = %RUN + %SYS - %OVRLP.
معمولاً معیار %USED آموزندهتر است.
٪صبر کن - چه مدت در طول دوره اندازه گیری فرآیند در حالت انتظار بوده است. شامل IDLE است.
%IDLE - چه مدت در طول دوره اندازه گیری فرآیند در حالت IDLE بوده است.
%SWPWT - چه مدت در طول دوره اندازه گیری vCPU منتظر عملیات با VMkernel Swap بوده است.
% VMWAIT - چه مدت زمان در طول دوره اندازه گیری vCPU در حالت انتظار برای یک رویداد (معمولا I / O) بوده است. هیچ شمارنده مشابهی در vCenter وجود ندارد. مقادیر بالا نشان دهنده مشکلات I/O در VM است.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
اگر VM از VMkernel Swap استفاده نمیکند، هنگام تجزیه و تحلیل مسائل مربوط به عملکرد، توصیه میشود به %VMWAIT نگاهی بیندازید، زیرا این معیار زمانی را که VM هیچ کاری انجام نداده است (%IDLE) در نظر نمیگیرد.
%RDY - چه مدت در طول دوره اندازه گیری فرآیند در حالت آماده بوده است.
%CSTP - چه مدت در طول دوره اندازه گیری فرآیند در حالت توقف بوده است.
%MLMTD - چه مدت در طول دوره اندازه گیری، به دلیل محدودیت منابع تنظیم شده، vCPU در حالت آماده بوده است.
%WAIT + %RDY + %CSTP + %RUN = 100% - هسته VM همیشه در یکی از این چهار حالت است.
CPU روی Hypervisor
vCenter همچنین دارای شمارنده های عملکرد CPU برای هایپروایزر است، اما آنها چیز جالبی نیستند - این فقط مجموع شمارنده های تمام ماشین های مجازی روی سرور است.
راحت ترین راه برای مشاهده وضعیت CPU در سرور در تب Summary است:
برای سرور، و همچنین برای ماشین مجازی، یک هشدار استاندارد وجود دارد:
وقتی بار روی CPU سرور زیاد است، ماشین های مجازی که روی آن کار می کنند شروع به تجربه مشکلات عملکرد می کنند.
در ESXTOP، داده های بارگذاری CPU سرور در بالای صفحه نمایش داده می شود. علاوه بر بار استاندارد CPU، که برای هایپروایزرها چندان آموزنده نیست، سه معیار دیگر نیز وجود دارد:
CORE UTIL(%) – بارگذاری هسته سرور فیزیکی این شمارنده نشان میدهد که هسته در طول دوره اندازهگیری چقدر زمان کار کرده است.
PCPU UTIL(%) - اگر hyper-threading فعال باشد، در این صورت دو رشته (PCPU) در هر هسته فیزیکی وجود دارد. این متریک نشان می دهد که هر رشته چه مدت کار کرده است.
PCPU استفاده شده (%) - مانند PCPU UTIL(%)، اما مقیاس فرکانس (یا کاهش فرکانس هسته برای صرفه جویی در مصرف انرژی، یا افزایش فرکانس هسته به دلیل فناوری Turbo Boost) و هایپر رشته را در نظر می گیرد.
PCPU_USED% = PCPU_UTIL% * ساعت هسته موثر / ساعت هسته اسمی.
در این اسکرین شات، برای برخی از هسته ها، به دلیل Turbo Boost، مقدار USED بیشتر از 100٪ است، زیرا فرکانس هسته بالاتر از فرکانس اسمی است.
چند کلمه در مورد اینکه چگونه هایپر نخ در نظر گرفته می شود. اگر فرآیندها در 100٪ مواقع در هر دو رشته هسته فیزیکی سرور اجرا شوند، در حالی که هسته در فرکانس اسمی اجرا می شود، آنگاه:
- CORE UTIL برای هسته 100٪ خواهد بود.
- PCPU UTIL برای هر دو رشته 100٪ خواهد بود.
- PCPU مورد استفاده برای هر دو رشته 50٪ خواهد بود.
اگر هر دو thread 100٪ در طول دوره اندازه گیری کار نمی کنند، در آن دوره هایی که thread ها به طور موازی کار می کنند، PCPU مورد استفاده برای هسته ها به نصف کاهش می یابد.
ESXTOP همچنین دارای یک صفحه نمایش با گزینه های قدرت CPU سرور است. در اینجا می توانید ببینید که آیا سرور از فناوری های صرفه جویی در انرژی استفاده می کند: حالت های C و P-states. با کلید "p" فراخوانی می شود:
مشکلات رایج عملکرد CPU
در نهایت، من به دلایل معمول مشکلات مربوط به عملکرد CPU VM می پردازم و نکات کوتاهی برای حل آنها ارائه می کنم:
ساعت هسته کافی نیست اگر امکان ارتقای ماشین مجازی به هستههای قدرتمندتر وجود ندارد، میتوانید تنظیمات برق را تغییر دهید تا Turbo Boost کارآمدتر عمل کند.
اندازه VM اشتباه (هسته های بسیار زیاد/کم). اگر هسته های کمی قرار دهید، بار زیادی روی CPU ماشین مجازی وارد می شود. اگر زیاد است، یک کوستاپ بالا بگیرید.
اشتراک بیش از حد CPU روی سرور. اگر VM آماده بالا است، اشتراک بیش از حد CPU را کاهش دهید.
توپولوژی NUMA اشتباه در ماشین های مجازی بزرگ. توپولوژی NUMA که توسط VM مشاهده می شود (vNUMA) باید با توپولوژی NUMA سرور (pNUMA) مطابقت داشته باشد. در مورد تشخیص و راه حل های ممکن برای این مشکل، به عنوان مثال، در کتاب نوشته شده است
برای من همه چیز مربوط به CPU است. سوال بپرس. در قسمت بعدی در مورد رم صحبت خواهم کرد.
لینک های مفید
منبع: www.habr.com