Steal: کسی که زمان CPU را از ماشین های مجازی می دزدد

سلام! من می خواهم به زبان ساده در مورد مکانیک ظهور سرقت در داخل ماشین های مجازی و در مورد برخی از مصنوعات غیر آشکاری که در طول تحقیقات او موفق به کشف آنها شدیم بگویم که من به عنوان مدیر فنی یک پلتفرم ابری مجبور شدم به آنها بپردازم. Mail.ru Cloud Solutions. این پلتفرم روی KVM اجرا می شود.

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

1. دزدی چیست

بنابراین، سرقت معیاری است که نشان دهنده کمبود زمان پردازشگر برای پردازش های داخل ماشین مجازی است. همانطور که توضیح داده شد در وصله هسته KVMsteal مدت زمانی است که هایپروایزر در حال اجرای سایر فرآیندها در سیستم عامل میزبان است، حتی اگر فرآیند ماشین مجازی را برای اجرا در صف قرار داده باشد. یعنی دزدی به عنوان تفاوت بین زمانی که فرآیند آماده اجرا است و زمانی که به پردازش زمان اختصاص داده می شود به CPU محاسبه می شود.

هسته ماشین مجازی متریک سرقت را از هایپروایزر دریافت می کند. در همان زمان، هایپروایزر مشخص نمی کند که چه فرآیندهای دیگری را انجام می دهد، فقط "در حالی که من مشغول هستم، نمی توانم به شما زمان بدهم." در KVM، پشتیبانی از محاسبه سرقت اضافه شده است تکه ها. در اینجا دو نکته کلیدی وجود دارد:

• ماشین مجازی در مورد سرقت از هایپروایزر یاد می گیرد. یعنی از نظر تلفات، برای فرآیندهای روی خود ماشین مجازی، این یک اندازه گیری غیر مستقیم است که می تواند در معرض اعوجاج های مختلفی باشد.
• هایپروایزر اطلاعاتی را در مورد کارهای دیگری که انجام می دهد با ماشین مجازی به اشتراک نمی گذارد - نکته اصلی این است که زمانی را به آن اختصاص نمی دهد. به همین دلیل، خود ماشین مجازی نمی‌تواند اعوجاج‌هایی را در نشانگر سرقت شناسایی کند، که می‌تواند بر اساس ماهیت فرآیندهای رقابتی ارزیابی شود.

2. آنچه بر دزدی تأثیر می گذارد

2.1. دزدی محاسبه

در واقع، دزدی تقریباً مانند زمان معمول استفاده از CPU در نظر گرفته می شود. اطلاعات زیادی در مورد نحوه بازیافت در نظر گرفته نشده است. احتمالاً به این دلیل که اکثریت این سؤال را بدیهی می دانند. اما در اینجا نیز مشکلاتی وجود دارد. برای مشاهده کلی این فرآیند، بخوانید مقاله برندان گرگ: هنگام محاسبه میزان استفاده و شرایطی که این محاسبه به دلایل زیر اشتباه می شود، با یک سری تفاوت های ظریف آشنا خواهید شد:

• گرم شدن بیش از حد پردازنده، که در آن چرخه ها نادیده گرفته می شوند.
• فعال/غیرفعال کردن توربو بوست، که فرکانس ساعت پردازنده را تغییر می دهد.
• تغییر در طول یک برش زمانی که هنگام استفاده از فناوری‌های صرفه‌جویی در انرژی پردازنده مانند SpeedStep رخ می‌دهد.
• محاسبه میانگین مشکل: تخمین استفاده یک دقیقه ای 80% می تواند یک انفجار کوتاه مدت 100% را پنهان کند.
• یک قفل چرخشی باعث می شود که پردازنده بازیابی شود، اما فرآیند کاربر هیچ پیشرفتی در اجرای خود نمی بیند. در نتیجه، استفاده تخمینی از پردازنده توسط فرآیند XNUMX٪ خواهد بود، اگرچه این فرآیند از نظر فیزیکی زمان پردازنده را مصرف نمی کند.

من مقاله ای پیدا نکردم که محاسبه مشابهی را برای سرقت توصیف کند (اگر می دانید، آن را در نظرات به اشتراک بگذارید). اما، با قضاوت بر اساس منابع، مکانیسم محاسبه مانند بازیافت است. فقط یک شمارنده دیگر در هسته اضافه می شود، مستقیماً برای فرآیند KVM (فرآیند ماشین مجازی) که مدت زمان پردازش KVM را در حالت انتظار پردازشگر محاسبه می کند. شمارنده اطلاعات مربوط به پردازنده را از مشخصات آن می گیرد و می بیند که آیا تمام تیک های آن توسط فرآیند ماشین مجازی استفاده می شود یا خیر. اگر همه چیز باشد، در نظر می گیریم که پردازنده فقط در فرآیند ماشین مجازی درگیر بوده است. در غیر این صورت، ما اطلاع می دهیم که پردازنده کار دیگری انجام می دهد، سرقت ظاهر شد.

روند شمارش سرقت با همان مشکلاتی روبرو است که تعداد سرقت معمولی وجود دارد. نمی توان گفت که چنین مشکلاتی اغلب ظاهر می شوند، اما ناامید کننده به نظر می رسند.

2.2. انواع مجازی سازی در KVM

به طور کلی، سه نوع مجازی سازی وجود دارد که همه آنها توسط KVM پشتیبانی می شوند. مکانیسم وقوع سرقت ممکن است به نوع مجازی سازی بستگی داشته باشد.

پخش. در این مورد، کار سیستم عامل ماشین مجازی با دستگاه های فیزیکی هایپروایزر چیزی شبیه به این است:

1. سیستم عامل مهمان فرمانی را به دستگاه مهمان خود ارسال می کند.
2. درایور دستگاه مهمان فرمان را دریافت می کند، درخواستی برای بایوس دستگاه ایجاد می کند و آن را به هایپروایزر ارسال می کند.
3. فرآیند Hypervisor یک فرمان را به یک فرمان برای یک دستگاه فیزیکی ترجمه می کند و از جمله موارد دیگر، آن را ایمن تر می کند.
4. درایور دستگاه فیزیکی دستور اصلاح شده را می پذیرد و آن را به خود دستگاه فیزیکی ارسال می کند.
5. نتایج اجرای دستورات در همان مسیر برمی گردد.

مزیت ترجمه این است که به شما امکان تقلید از هر دستگاهی را می دهد و نیازی به آماده سازی خاصی از هسته سیستم عامل ندارد. اما شما باید اول از همه با سرعت برای این کار هزینه کنید.

مجازی سازی سخت افزار. در این حالت دستگاه در سطح سخت افزاری دستورات سیستم عامل را درک می کند. این سریع ترین و بهترین راه است. اما، متأسفانه، توسط همه دستگاه های فیزیکی، هایپروایزر و سیستم عامل های مهمان پشتیبانی نمی شود. در حال حاضر، دستگاه های اصلی که از مجازی سازی سخت افزار پشتیبانی می کنند، پردازنده ها هستند.

فرا مجازی سازی. رایج ترین گزینه برای مجازی سازی دستگاه در KVM و به طور کلی رایج ترین حالت مجازی سازی برای سیستم عامل های مهمان. ویژگی آن این است که کار با برخی از زیرسیستم های Hypervisor (به عنوان مثال، با شبکه یا پشته دیسک) یا تخصیص صفحات حافظه با استفاده از Hypervisor API بدون ترجمه دستورات سطح پایین انجام می شود. نقطه ضعف این روش مجازی سازی این است که هسته سیستم عامل مهمان باید اصلاح شود تا بتواند با استفاده از این API با هایپروایزر ارتباط برقرار کند. اما این مشکل معمولا با نصب درایورهای خاص بر روی سیستم عامل مهمان حل می شود. در KVM این API نامیده می شود virtio API.

با paravirtualization، در مقایسه با ترجمه، با ارسال دستورات مستقیم از ماشین مجازی به فرآیند Hypervisor روی میزبان، مسیر دستگاه فیزیکی به طور قابل توجهی کاهش می یابد. این به شما اجازه می دهد تا سرعت اجرای تمام دستورالعمل های داخل ماشین مجازی را افزایش دهید. در KVM، virtio API مسئول این کار است که فقط برای دستگاه‌های خاصی مانند آداپتور شبکه یا دیسک کار می‌کند. به همین دلیل است که درایورهای virtio در داخل ماشین های مجازی نصب می شوند.

طرف معکوس این شتاب این است که تمام فرآیندهایی که در داخل ماشین مجازی اجرا می شوند در داخل آن باقی نمی مانند. این باعث ایجاد برخی جلوه‌های ویژه می‌شود که ممکن است باعث ظاهر شدن سرقت شود. توصیه می کنم مطالعه دقیق این موضوع را با یک API برای I/O مجازی: virtio.

2.3. برنامه ریزی "عادلانه".

ماشین مجازی روی هایپروایزر در واقع یک فرآیند منظم است که از قوانین زمان بندی (توزیع منابع بین فرآیندها) در هسته لینوکس پیروی می کند، بنابراین اجازه دهید نگاهی دقیق تر به آن بیندازیم.

لینوکس از CFS به نام Completely Fair Scheduler استفاده می کند که از زمان هسته 2.6.23 به زمانبندی پیش فرض تبدیل شده است. برای درک این الگوریتم، می توانید معماری هسته لینوکس یا منبع را مطالعه کنید. ماهیت CFS در توزیع زمان پردازنده بین فرآیندها بسته به مدت زمان اجرای آنها نهفته است. هرچه یک فرآیند به زمان CPU بیشتری نیاز داشته باشد، زمان CPU کمتر می شود. این کار اجرای "عادلانه" همه فرآیندها را تضمین می کند - به طوری که یک فرآیند همیشه همه پردازنده ها را اشغال نمی کند و سایر فرآیندها نیز می توانند اجرا شوند.

گاهی اوقات این پارادایم به مصنوعات جالبی منجر می شود. کاربران قدیمی لینوکس مطمئناً فریز کردن یک ویرایشگر متن معمولی روی دسکتاپ را در طول راه اندازی برنامه های کاربردی با منابع فشرده مانند کامپایلر به خاطر خواهند آورد. این اتفاق به این دلیل رخ داد که وظایف غیرمصرف برنامه های دسکتاپ با وظایفی که به طور فعال منابع را مصرف می کنند، مانند کامپایلر رقابت می کردند. CFS فکر می کند این ناعادلانه است، بنابراین به طور دوره ای ویرایشگر متن را متوقف می کند و به پردازنده اجازه می دهد تا وظایف کامپایلر را انجام دهد. این با مکانیسم اصلاح شد sched_autogroup، اما بسیاری از ویژگی های دیگر از توزیع زمان پردازنده بین وظایف باقی مانده است. در واقع، این داستان درباره بد بودن همه چیز در CFS نیست، بلکه تلاشی برای جلب توجه به این واقعیت است که توزیع "عادلانه" زمان پردازنده پیش پا افتاده ترین کار نیست.

یکی دیگر از نکات مهم در زمانبندی، پیش دستی است. این برای حذف فرآیند snickering از پردازنده و اجازه دادن به دیگران برای کار ضروری است. فرآیند تبعید را تغییر زمینه، سوئیچ زمینه پردازشگر می نامند. در همان زمان، کل زمینه کار ذخیره می شود: وضعیت پشته، رجیسترها و غیره، پس از آن فرآیند به انتظار فرستاده می شود و دیگری جای آن را می گیرد. این یک عملیات گران قیمت برای سیستم عامل است، و به ندرت استفاده می شود، اما در واقع هیچ مشکلی با آن وجود ندارد. تغییر متن مکرر ممکن است نشان دهنده وجود مشکل در سیستم عامل باشد، اما معمولاً به طور مداوم ادامه می یابد و چیز خاصی را نشان نمی دهد.

چنین داستان طولانی برای توضیح یک واقعیت مورد نیاز است: هر چه یک فرآیند سعی کند منابع پردازنده بیشتری را در یک زمان‌بندی صادق لینوکس مصرف کند، سریع‌تر متوقف می‌شود تا سایر فرآیندها نیز بتوانند کار کنند. این که آیا این درست است یا نه یک سوال دشوار است که در بارهای مختلف به طور متفاوتی حل می شود. در ویندوز، تا همین اواخر، زمان‌بندی بر روی پردازش اولویت‌بندی برنامه‌های دسکتاپ متمرکز بود، که می‌توانست باعث توقف فرآیندهای پس‌زمینه شود. Sun Solaris دارای پنج کلاس مختلف زمان‌بندی بود. هنگامی که مجازی سازی راه اندازی شد، ششمین مورد اضافه شد. زمانبندی سهم منصفانهزیرا پنج مورد قبلی به اندازه کافی با مجازی سازی Solaris Zones کار نمی کردند. توصیه می کنم مطالعه دقیق این موضوع را با کتاب هایی مانند Solaris Internals: Solaris 10 و OpenSolaris Kernel Architecture یا شناخت هسته لینوکس.

2.4. چگونه سرقت را رصد کنیم؟

نظارت بر سرقت در داخل یک ماشین مجازی، مانند هر معیار دیگر پردازنده، ساده است: می توانید از هر ابزار متریک پردازنده استفاده کنید. نکته اصلی این است که ماشین مجازی باید روی لینوکس باشد. ویندوز به دلایلی چنین اطلاعاتی را در اختیار کاربران خود قرار نمی دهد. 🙁

خروجی دستور بالا: جزئیات بار روی پردازنده، در سمت راست ترین ستون - سرقت

مشکل هنگام تلاش برای دریافت این اطلاعات از هایپروایزر ایجاد می شود. می توانید سعی کنید سرقت را در ماشین میزبان پیش بینی کنید، به عنوان مثال، با پارامتر Load Average (LA) - مقدار متوسط ​​تعداد فرآیندهای منتظر در صف اجرا. روش محاسبه این پارامتر ساده نیست، اما به طور کلی، اگر LA نرمال شده توسط تعداد رشته های پردازنده بیشتر از 1 باشد، این نشان می دهد که سرور لینوکس با چیزی بیش از حد بارگذاری شده است.

همه این فرآیندها منتظر چه چیزی هستند؟ پاسخ واضح پردازنده ها هستند. اما پاسخ کاملاً صحیح نیست، زیرا گاهی اوقات پردازنده رایگان است و LA از مقیاس خارج می شود. یاد آوردن چگونه NFS سقوط می کند و چگونه LA در همان زمان رشد می کند. تقریباً همین امر می تواند با دیسک و سایر دستگاه های ورودی / خروجی باشد. اما در واقع، فرآیندها می توانند منتظر پایان هر قفلی باشند، چه فیزیکی، مرتبط با دستگاه I/O و چه منطقی، مانند mutex. همچنین شامل قفل‌هایی در سطح سخت‌افزار (همان پاسخ از دیسک)، یا منطق (اصطلاحاً قفل‌کننده‌های اولیه است که شامل مجموعه‌ای از موجودیت‌ها، mutex adaptive و spin، سمافورها، متغیرهای شرط، قفل‌های rw، قفل‌های ipc می‌شود. ..).

یکی دیگر از ویژگی های LA این است که به عنوان یک مقدار متوسط ​​برای سیستم عامل در نظر گرفته می شود. به عنوان مثال، 100 پردازش برای یک فایل با هم رقابت می کنند و سپس LA=50. به نظر می رسد چنین مقدار زیادی نشان دهنده بد بودن سیستم عامل است. اما برای سایر کدهای اشتباه نوشته شده، این می تواند یک حالت عادی باشد، علیرغم این واقعیت که فقط آن بد است و سایر فرآیندهای سیستم عامل آسیب نمی بینند.

به دلیل این میانگین گیری (و نه کمتر از یک دقیقه)، تعیین هر چیزی از نظر LA، با نتایج بسیار نامطمئن در موارد خاص، سودمندترین کار نیست. اگر سعی کنید آن را کشف کنید، متوجه خواهید شد که مقالات موجود در ویکی‌پدیا و سایر منابع موجود، تنها ساده‌ترین موارد را توصیف می‌کنند، بدون توضیح عمیق درباره فرآیند. من دوباره برای همه علاقه مندان ارسال می کنم اینجا به برندان گرگ  - لینک ها را دنبال کنید چه کسی در انگلیسی تنبل است - ترجمه مقاله محبوب او درباره لس آنجلس.

3. جلوه های ویژه

حال بیایید به پرونده های اصلی سرقتی که با آنها برخورد کرده ایم بپردازیم. من به شما خواهم گفت که چگونه آنها از همه موارد بالا پیروی می کنند و چگونه با شاخص های موجود در هایپروایزر ارتباط دارند.

بازیافت. ساده ترین و رایج ترین: هایپروایزر بازیافت می شود. در واقع، تعداد زیادی ماشین مجازی در حال اجرا وجود دارد، مصرف پردازنده بالا در داخل آنها، رقابت زیاد، استفاده توسط LA بیشتر از 1 است (نرمال شده توسط رشته های پردازنده). در داخل تمام virtualok همه چیز کند می شود. سرقت منتقل شده از هایپروایزر نیز رشد می کند، لازم است بار را مجدداً توزیع کنید یا شخصی را خاموش کنید. به طور کلی، همه چیز منطقی و قابل درک است.

Paravirtualization در مقابل نمونه های تنها. فقط یک ماشین مجازی روی هایپروایزر وجود دارد، بخش کوچکی از آن را مصرف می کند، اما یک بار ورودی / خروجی بزرگ، به عنوان مثال، روی یک دیسک می دهد. و از جایی یک دزدی کوچک در آن ظاهر می شود، تا 10٪ (همانطور که چندین آزمایش نشان می دهد).

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

این اتفاق در لحظه ارسال بافر می افتد، به فضای هسته Hypervisor می رود و ما شروع به انتظار برای آن می کنیم. اگرچه از نظر ماشین مجازی باید فوراً برگردد. بنابراین با توجه به الگوریتم محاسبه سرقت، این زمان به سرقت رفته در نظر گرفته می شود. به احتمال زیاد، ممکن است مکانیسم های دیگری در این شرایط وجود داشته باشد (مثلاً پردازش برخی از تماس های sys بیشتر)، اما آنها نباید تفاوت زیادی داشته باشند.

زمانبندی در برابر ماشین های مجازی با بارگذاری بالا. هنگامی که یک ماشین مجازی بیشتر از دیگران از سرقت رنج می برد، این دقیقاً به دلیل زمانبندی است. هرچه فرآیند بیشتر پردازنده را بارگذاری کند، زمان‌بندی زودتر آن را بیرون می‌آورد تا بقیه نیز بتوانند کار کنند. اگر یک ماشین مجازی کمی مصرف کند، به سختی دزدی را می بیند: روند آن صادقانه نشست و منتظر ماند، باید زمان بیشتری به آن داده شود. اگر ماشین مجازی حداکثر بار را روی تمام هسته‌های خود تولید کند، بیشتر اوقات از پردازنده خارج می‌شود و سعی می‌کنند زمان زیادی به آن ندهند.

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

LA پایین است، اما سرقت وجود دارد. اگر LA حدود 0,7 باشد (یعنی به نظر می رسد هایپروایزر کم بار است)، اما سرقت در داخل ماشین های مجازی فردی مشاهده می شود:

• گزینه ای که قبلاً در بالا با paravirtualization توضیح داده شد. ماشین مجازی می تواند معیارهایی را دریافت کند که نشان دهنده سرقت است، اگرچه هایپروایزر به خوبی کار می کند. با توجه به نتایج آزمایش‌های ما، این گزینه سرقت از 10 درصد تجاوز نمی‌کند و نباید تأثیر قابل‌توجهی بر عملکرد برنامه در داخل ماشین مجازی داشته باشد.
• پارامتر LA نادرست در نظر گرفته می شود. به طور دقیق تر، در هر لحظه خاص صحیح در نظر گرفته می شود، اما زمانی که میانگین آن بیش از یک دقیقه باشد، معلوم می شود که دست کم گرفته می شود. به عنوان مثال، اگر یک ماشین مجازی در هر یک سوم هایپروایزر تمام پردازنده های خود را دقیقاً برای نیم دقیقه مصرف کند، LA در هر دقیقه در هایپروایزر 0,15 خواهد بود. چهار ماشین مجازی که به طور همزمان کار می کنند 0,6 می دهند. و این واقعیت که برای هر یک از آنها به مدت نیم دقیقه یک سرقت وحشی در 25٪ از نظر LA وجود داشت، دیگر نمی توان بیرون کشید.
• باز هم به خاطر برنامه‌ریزی که به این نتیجه رسید که یک نفر بیش از حد غذا می‌خورد، و بگذارید این کسی منتظر بماند. در ضمن، من زمینه را تغییر می‌دهم، وقفه‌ها را مدیریت می‌کنم و به سایر موارد مهم سیستم رسیدگی می‌کنم. در نتیجه، برخی از ماشین های مجازی هیچ مشکلی را مشاهده نمی کنند، در حالی که برخی دیگر با کاهش شدید عملکرد مواجه می شوند.

4. سایر تحریفات

میلیون‌ها دلیل دیگر برای تحریف بازگشت صادقانه زمان پردازنده در ماشین مجازی وجود دارد. برای مثال، hyperthreading و NUMA به محاسبات پیچیدگی اضافه می کنند. آنها به طور کامل انتخاب هسته را برای اجرای فرآیند اشتباه می گیرند، زیرا زمانبندی از ضرایب - وزن استفاده می کند، که هنگام تغییر زمینه، محاسبه را دشوارتر می کند.

به دلیل فن آوری هایی مانند تقویت توربو یا برعکس حالت صرفه جویی در انرژی، اعوجاج هایی وجود دارد که هنگام محاسبه استفاده، می تواند به طور مصنوعی فرکانس یا حتی کوانتوم زمانی روی سرور را افزایش یا کاهش دهد. فعال کردن توربو بوست عملکرد یک رشته پردازنده را به دلیل افزایش عملکرد رشته دیگر کاهش می دهد. در این لحظه، اطلاعات مربوط به فرکانس فعلی پردازنده به ماشین مجازی مخابره نمی شود و معتقد است که شخصی در حال دزدیدن زمان آن است (مثلاً 2 گیگاهرتز درخواست کرده است، اما نصف آن را دریافت کرده است).

به طور کلی، دلایل زیادی برای اعوجاج وجود دارد. در یک سیستم خاص، ممکن است چیز دیگری پیدا کنید. بهتر است با کتاب هایی که در بالا به آنها پیوند دادم شروع کنید و با خواندن آمار از Hypervisor با ابزارهایی مانند perf، sysdig، systemtap که از آنها استفاده می کنید. دهها.

5. نتیجه گیری

1. مقدار مشخصی از سرقت می تواند به دلیل مجازی سازی اتفاق بیفتد و می توان آن را طبیعی در نظر گرفت. در اینترنت می نویسند که این مقدار می تواند 5-10٪ باشد. این بستگی به برنامه های داخل ماشین مجازی و میزان بارگذاری آن به دستگاه های فیزیکی خود دارد. در اینجا مهم است که به احساس برنامه ها در داخل ماشین های مجازی توجه کنید.
2. نسبت بار روی هایپروایزر و سرقت در داخل ماشین مجازی همیشه به طور واضح به هم مرتبط نیست، هر دو تخمین سرقت می توانند در موقعیت های خاص در بارهای مختلف اشتباه باشند.
3. برنامه‌ریز نگرش بدی نسبت به فرآیندهایی دارد که تقاضای زیادی دارند. او سعی می کند به کسانی که بیشتر می خواهند کمتر بدهد. ماشین های مجازی بزرگ بد هستند.
4. یک سرقت کوچک حتی بدون مجازی‌سازی (با در نظر گرفتن بار داخل ماشین مجازی، ویژگی‌های بار همسایگان، توزیع بار بین رشته‌ها و عوامل دیگر) می‌تواند عادی باشد.
5. اگر می‌خواهید سرقت را در یک سیستم خاص کشف کنید، باید گزینه‌های مختلف را بررسی کنید، معیارها را جمع‌آوری کنید، آنها را به دقت تجزیه و تحلیل کنید و به نحوه توزیع یکنواخت بار فکر کنید. انحرافات از هر موردی ممکن است، که باید به صورت آزمایشی تأیید شود یا در اشکال‌زدای هسته بررسی شود.

منبع: www.habr.com