عیب‌یابی کندی ماشین مجازی؛ CPU، حافظه، دیسک و شبکه

این راهنما برای کارشناس مجاز و VMهای ویندوزی روی ESXi 8.x یا Hyper-V در Windows Server 2025 است؛ مهمان نمونه Windows Server 2022 است. مستندات Broadcom و Microsoft در ۱۵ اکتبر ۲۰۲۶ تطبیق داده شدند. نام و دسترسی بعضی شمارنده‌ها با نسخه و زبان سیستم فرق می‌کند. اعداد خروجی آزمایش واقعی در این صفحه ارائه نشده‌اند.

اگر برنامه اصلاً باز نمی‌شود، راهنمای سرور روشن و برنامه قطع را ببینید. اگر فقط یک کاربر کند است، وضعیت کلاینت و مسیر او نیز مطرح است. بازسازی VM، حذف Snapshot یا خاموش‌کردن حفاظت میزبان، قدم آغازین این بررسی نیست.

• کار مشخص را نام ببرید: مثلاً بازکردن یک گزارش با داده یکسان یا انتقال فایل آزمایشی مجاز به مقصد ثابت. زمان پاسخ و خطا را ثبت کنید؛ «سرور کند است» برای مقایسه کافی نیست.
• بازه کندی، تعداد کاربران و کارهای هم‌زمان مثل بکاپ، به‌روزرسانی یا اسکن را بنویسید. ساعت میزبان و مهمان باید برای مقایسه رخدادها هماهنگ باشد.
• مشخص کنید یک VM، چند VM روی یک میزبان یا ماشین‌های متصل به یک datastore درگیرند. اشتراک در میزبان، دیسک یا uplink مسیر بررسی را کوتاه می‌کند؛ علت را قطعی ثابت نمی‌کند.
• نسخه و Build، vCPU، حافظه، Limit/Reservation، نوع دیسک و فضای آزاد، Snapshot/Checkpoint و تغییر اخیر را ثبت کنید. پیش از تغییر، تنظیم قبلی و راه برگشت روشن باشد.

کندی فقط در کنسول یا RDP را از کندی خود برنامه جدا کنید. اگر کنسول تصویر دیر نشان می‌دهد ولی کار برنامه از کلاینت عادی است، افزایش CPU ممکن است مسئله اصلی را هدف نگیرد.

در ویندوز مهمان، Task Manager و Resource Monitor را برای پردازش درگیر، حافظه، I/O و شبکه ببینید. برای روند قابل مقایسه، از Performance Monitor استفاده کنید. در Hyper-V، نمودار CPU سیستم‌عامل میزبان جای همه شمارنده‌های Hypervisor را نمی‌گیرد؛ مصرف میزبان و VM باید با شاخص مناسب خوانده شود.

روی ESXi، ابتدا نمودارها و هشدارهای مدیریت را بررسی کنید. برای بررسی دقیق‌تر، esxtop را از Shell یا SSH مجازِ محدود به شبکه مدیریت اجرا کنید؛ اگر SSH فقط برای تشخیص فعال شده، پس از پایان آن را ببندید. این مشاهده، تست فشار یا فرمان تغییر منابع نیست.

esxtop

مدت و فاصله نمونه‌گیری را طوری انتخاب کنید که بازه کندی پوشش داده شود؛ یک عکس لحظه‌ای کافی نیست. ردیف کل VM با ردیف هر vCPU، درصد با مقدار تجمعی و میانگین چنددقیقه‌ای با قله کوتاه یکسان نیستند. پیش از مقایسه، واحد و دامنه شمارنده را ثبت کنید.

در ESXi، %RDY زمانی را نشان می‌دهد که VM آماده اجرا بوده ولی زمان پردازنده نگرفته است. افزایش پایدار آن همراه کندی، بررسی رقابت روی میزبان، vCPUهای بیش از نیاز و CPU Limit را لازم می‌کند. این شاخص همان درصد CPU داخل ویندوز نیست. اگر عدد در ردیف تجمیعی ماشین دیده می‌شود، آن را با آستانه هر vCPU مقایسه نکنید.

در Hyper-V، شمارنده‌های Hyper-V Hypervisor Logical Processor و Hyper-V Hypervisor Virtual Processor با % Total Run Time کمک می‌کنند بار میزبان را از پردازنده‌های مجازی جدا ببینید. در مهمان هم پردازش و توزیع بار بین هسته‌ها را بررسی کنید؛ شلوغی یک هسته می‌تواند در میانگین کل پنهان بماند.

Affinity، NUMA یا تعداد هسته را تصادفی عوض نکنید. برای VM بزرگ، چیدمان NUMA و توصیه سازنده برنامه نیازمند بررسی دقیق‌تر است. نتیجه باید در زمان پاسخ همان کار دیده شود، نه فقط کاهش یک درصد.

داخل مهمان، حافظه در دسترس، رشد مصرف پردازش و Paging را کنار بار کار ببینید. روی ESXi، MCTLSZ مقدار بازپس‌گیری با Balloon و SWCUR مقدار Swap میزبان است؛ نرخ‌های SWR/s و SWW/s فعالیت جاری را نشان می‌دهند. وجود Swap ذخیره‌شده به‌تنهایی ثابت نمی‌کند که اکنون I/O ناشی از آن عامل کندی است.

در Hyper-V، Memory → Available MBytes را در میزبان و مهمان و در صورت استفاده از Dynamic Memory، مقدارهای Assigned/Demand و سقف حافظه VM را مقایسه کنید. سقف بالاتر برای VM، RAM فیزیکی تازه ایجاد نمی‌کند. اگر میزبان هم تحت فشار است، افزایش حافظه همه VMها راه‌حل نیست. برای حافظه‌ای که Hyper-V می‌تواند به ماشین‌ها بدهد، شمارنده Hyper-V Dynamic Memory Balancer → Available Memory را هم ببینید؛ RAM آزاد عمومی سیستم‌عامل میزبان به‌تنهایی نمای کامل ظرفیت قابل تخصیص نیست.

اگر فقط مهمان کمبود تأییدشده دارد و میزبان ظرفیت دارد، حافظه آن را متناسب با برنامه افزایش دهید. اگر فشار مشترک است، زمان بارها، جابه‌جایی مجاز VM یا ظرفیت میزبان را بررسی کنید. Balloon Driver یا Pagefile را صرفاً برای پنهان‌شدن شاخص خاموش نکنید؛ این کار علت کمبود را حذف نمی‌کند.

هم فضای داخل ویندوز و هم فضای datastore یا Volume میزبان را ببینید. دیسک مجازی Thin/Dynamic می‌تواند در مهمان فضای خالی نشان دهد ولی محل واقعی فایل‌ها به کمبود برسد. در مقابل، ذخیره‌ساز دارای فضای آزاد هم ممکن است زیر بار، تأخیر یا خطای I/O داشته باشد.

در ESXi، DAVG تأخیر سمت دستگاه/ذخیره‌ساز و KAVG بخش تأخیر VMkernel است؛ GAVG حاصل جمع آن‌هاست. آن‌ها را با همان VM یا مسیر ذخیره‌سازی، حجم I/O و زمان مشکل تطبیق دهید. افزایش DAVG بررسی دیسک، کنترلر و مسیر ذخیره‌ساز را مهم می‌کند؛ افزایش KAVG بررسی صف و محدودیت مسیر میزبان را لازم دارد. هیچ‌کدام به‌تنهایی دستور تغییر Queue Depth نیست.

در Hyper-V و مهمان ویندوزی، Avg. Disk sec/Read و Avg. Disk sec/Write را همراه تعداد عملیات و طول صف بررسی کنید. واحد این شمارنده ثانیه است؛ برای نمونه 0.020 ثانیه برابر ۲۰ میلی‌ثانیه است. این مثال تبدیل واحد است و حد قبولی همه برنامه‌ها نیست.

هم‌زمانی بکاپ، رشد Snapshot/Checkpoint، خطای کنترلر و هشدار فضای آزاد را بررسی کنید. حذف دستی فایل delta یا avhdx می‌تواند زنجیره دیسک را خراب کند. Consolidation یا Merge باید از ابزار رسمی، با فضای کافی و زمان هماهنگ انجام شود؛ عملیات در حال اجرا را برای رفع کندی قطع نکنید. Snapshot بکاپ مستقل نیست.

یک تغییر اولیه قابل سنجش می‌تواند جابه‌جایی زمان یک کار سنگینِ غیرضروری باشد. اگر تأخیر و زمان پاسخ هم‌زمان بهتر شدند، این سرنخ را با تکرار و بررسی ظرفیت تکمیل کنید؛ از آن نتیجه نگیرید که همیشه باید بکاپ را حذف یا ذخیره‌ساز را عوض کرد.

کارت مجازی، Port group یا vSwitch، VLAN، uplink فیزیکی و مقصد برنامه را دنبال کنید. سرعت اسمی کارت مجازی، ظرفیت واقعی مسیر تا کاربر نیست. روی ESXi، Dropهای ارسال/دریافت را با ترافیک و کارت واقعی مقایسه کنید؛ روی Hyper-V، مصرف کارت فیزیکی و آداپتور VM را جدا ببینید.

وقتی کار داخل مهمان عادی است ولی از کلاینت کند می‌شود، مسیر شبکه، DNS و ارتباط برنامه با سرویس‌های دیگر مهم‌تر می‌شوند. در یک بازه مجاز، سنجش انتقال داخلی با iperf3 می‌تواند بخش شبکه را جدا بررسی کند؛ نتیجه آن سرعت پایگاه داده یا دیسک نیست و آزمون سنگین را روی ساعت کاری بدون ظرفیت آزاد اجرا نکنید.

Driver و ابزار یکپارچه‌سازی سازگار را کنترل کنید. Jumbo Frame، Offload، VMQ یا تعداد صف را بدون شاهد و هماهنگی کل مسیر عوض نکنید. اگر منابع و مسیر سالم‌اند، قفل، Query، مجوز و وابستگی خود برنامه باید با پشتیبان آن بررسی شوند.

• فرضیه را بنویسید: مثلاً رقابت ذخیره‌سازی هنگام بکاپ؛ شاهد و کار قابل تکرار را مشخص کنید.
• اثر تغییر بر دیگر VMها و نیاز به خاموشی را بررسی کنید. تنظیم فعلی و بکاپ لازم را حفظ کنید؛ تغییر vCPU یا حافظه در همه نسخه‌ها و شرایط بدون توقف نیست.
• فقط یک تغییر مرتبط انجام دهید؛ مانند اصلاح Limit اشتباه، اندازه‌گذاری تأییدشده یا تغییر زمان کار سنگین.
• همان آزمون با داده، کاربر و بار قابل مقایسه را تکرار کنید. زمان پاسخ، خطا و روند منابع میزبان و مهمان را کنار هم ثبت کنید.
• اگر نتیجه قابل تکرار نیست یا VM دیگری آسیب دیده، تنظیم را برگردانید و فرضیه بعدی را با شاهد بررسی کنید. تغییرات پذیرفته‌شده و مسئول پیگیری ثبت شوند.

برای مثال فرضی، اگر کندی گزارش فقط هنگام بکاپ رخ می‌دهد، ابتدا روند تأخیر دیسک و بار همان بازه را ثبت کنید. با جابه‌جایی زمان بکاپ و ثابت‌ماندن کار گزارش، می‌توان اثر هم‌زمانی را بررسی کرد. این مثال نتیجه آزمایش نت‌مسترز نیست و جای تحلیل Query یا دیگر وابستگی‌ها را نمی‌گیرد.

اگر مسئله به ظرفیت تأییدشده میزبان رسیده است، راهنمای ارتقا یا تعویض سرور به تصمیم بعدی کمک می‌کند. برای رسیدگی موردی یا نگهداری، پشتیبانی سرور در دسترس است؛ خرید سخت‌افزار باید به علت مشخص متصل باشد.