مرحبًا! أريد أن أخبركم بعبارات بسيطة عن آليات السرقة داخل الأجهزة الافتراضية وعن بعض القطع الأثرية غير الواضحة التي تمكنا من اكتشافها خلال بحثها، والتي كان علي أن أتعمق فيها كمدير فني لمنصة سحابية . تعمل المنصة على KVM.
وقت سرقة وحدة المعالجة المركزية هو الوقت الذي لا يتلقى فيه الجهاز الظاهري موارد المعالج لتنفيذه. يتم احتساب هذه المرة فقط في أنظمة التشغيل الضيف في بيئات المحاكاة الافتراضية. إن الأسباب التي تحدد أين تذهب هذه الموارد الأكثر تخصيصًا، كما هو الحال في الحياة، غامضة للغاية. لكننا قررنا اكتشاف ذلك، وقمنا بإجراء عدد من التجارب. لا يعني ذلك أننا نعرف الآن كل شيء عن السرقة، ولكننا سنخبرك بشيء مثير للاهتمام الآن.
1. ما هي السرقة
لذا، فإن السرقة هي مقياس يشير إلى نقص وقت المعالج للعمليات داخل الجهاز الظاهري. كما وصفت التخفي هو الوقت الذي يقوم فيه برنامج Hypervisor بتنفيذ عمليات أخرى على نظام التشغيل المضيف على الرغم من أنه قام بوضع عملية الجهاز الظاهري في قائمة الانتظار للتنفيذ. أي أنه يتم حساب السرقة على أنها الفرق بين الوقت الذي تكون فيه العملية جاهزة للتنفيذ والوقت الذي يتم فيه تخصيص وقت المعالج للعملية.
تتلقى نواة الجهاز الظاهري مقياس السرقة من برنامج Hypervisor. وفي الوقت نفسه، لا يحدد برنامج Hypervisor بالضبط ما هي العمليات الأخرى التي يقوم بتشغيلها، بل يقول ببساطة "أثناء انشغالي، لا أستطيع أن أعطيك الوقت". في KVM، تمت إضافة دعم لحسابات السرقة إلى . هناك نقطتان رئيسيتان هنا:
- تتعلم الآلة الافتراضية كيفية السرقة من برنامج Hypervisor. وهذا يعني، من وجهة نظر الخسائر، بالنسبة للعمليات على الجهاز الظاهري نفسه، يعد هذا قياسًا غير مباشر يمكن أن يخضع لتشوهات مختلفة.
- لا يشارك برنامج Hypervisor المعلومات مع الجهاز الظاهري حول ما يفعله أيضًا - الشيء الرئيسي هو أنه لا يخصص وقتًا لذلك. ولهذا السبب، لا تستطيع الآلة الافتراضية نفسها اكتشاف التشوهات في مؤشر السرقة، والتي يمكن تقييمها حسب طبيعة العمليات المتنافسة.
2. ما يؤثر على السرقة
2.1. سرقة الحساب
بشكل أساسي، يتم حساب السرقة تقريبًا بنفس وقت استخدام وحدة المعالجة المركزية العادية. لا يوجد الكثير من المعلومات حول كيفية النظر في إعادة التدوير. ربما لأن معظم الناس يعتبرون هذا السؤال واضحًا. ولكن هناك أيضا مطبات هنا. للتعرف على هذه العملية، يمكنك أن تقرأ : سوف تتعرف على الكثير من الفروق الدقيقة عند حساب الاستخدام وعن المواقف التي يكون فيها هذا الحساب خاطئًا للأسباب التالية:
- ترتفع درجة حرارة المعالج، مما يؤدي إلى تخطي الدورات.
- تمكين/تعطيل تعزيز التربو، الذي يغير سرعة ساعة المعالج.
- تغيير في طول الشريحة الزمنية الذي يحدث عند استخدام تقنيات توفير طاقة المعالج مثل SpeedStep.
- المشكلة في حساب المتوسط: تقدير استخدام دقيقة واحدة بنسبة 80% يمكن أن يخفي انفجارًا قصير المدى بنسبة 100%.
- يؤدي قفل الدوران إلى استعادة المعالج، لكن عملية المستخدم لا ترى أي تقدم في تنفيذها. ونتيجة لذلك، سيكون استخدام المعالج المحسوب بواسطة العملية مائة بالمائة، على الرغم من أن العملية لن تستهلك وقت المعالج فعليًا.
لم أجد مقالًا يصف حسابًا مشابهًا للسرقة (إذا كنت تعرف ذلك، شاركه في التعليقات). ولكن، إذا حكمنا من خلال الكود المصدري، فإن آلية الحساب هي نفسها المستخدمة في إعادة التدوير. ببساطة، تتم إضافة عداد آخر في النواة، مباشرةً لعملية KVM (عملية الآلة الافتراضية)، والذي يحسب مدة انتظار عملية KVM لوقت وحدة المعالجة المركزية. يأخذ العداد معلومات حول المعالج من مواصفاته ويتحقق مما إذا كانت جميع علامات التجزئة الخاصة به يتم استخدامها من خلال عملية الجهاز الظاهري. إذا كان هذا كل شيء، فإننا نفترض أن المعالج كان مشغولاً فقط بعملية الآلة الافتراضية. خلاف ذلك، نعلم أن المعالج كان يفعل شيئا آخر، ظهرت سرقة.
تخضع عملية عد المسروقات لنفس المشكلات التي تتعرض لها عملية عد إعادة التدوير العادية. لا يعني أن مثل هذه المشاكل تظهر في كثير من الأحيان، لكنها تبدو محبطة.
2.2. أنواع المحاكاة الافتراضية على KVM
بشكل عام، هناك ثلاثة أنواع من المحاكاة الافتراضية، وكلها مدعومة من قبل KVM. قد تعتمد آلية حدوث السرقة على نوع المحاكاة الافتراضية.
ترجمة. في هذه الحالة، يحدث تشغيل نظام تشغيل الجهاز الظاهري باستخدام أجهزة Hypervisor الفعلية على النحو التالي:
- يرسل نظام التشغيل الضيف أمرًا إلى جهاز الضيف الخاص به.
- يتلقى برنامج تشغيل الجهاز الضيف الأمر، ويقوم بإنشاء طلب لنظام BIOS الخاص بالجهاز ويرسله إلى برنامج Hypervisor.
- تقوم عملية برنامج Hypervisor بترجمة الأمر إلى أمر للجهاز الفعلي، مما يجعله، من بين أمور أخرى، أكثر أمانًا.
- يقبل برنامج تشغيل الجهاز الفعلي الأمر المعدل ويرسله إلى الجهاز الفعلي نفسه.
- تعود نتائج تنفيذ الأوامر على نفس المسار.
ميزة الترجمة هي أنها تسمح لك بمحاكاة أي جهاز ولا تتطلب إعدادًا خاصًا لنواة نظام التشغيل. لكن عليك أن تدفع ثمن هذا أولاً وقبل كل شيء بالسرعة.
المحاكاة الافتراضية للأجهزة. في هذه الحالة، يفهم الجهاز على مستوى الأجهزة الأوامر الصادرة من نظام التشغيل. هذه هي الطريقة الأسرع والأفضل. ولكن، لسوء الحظ، لا يتم دعمه من قبل جميع الأجهزة المادية وبرامج Hypervisor وأنظمة التشغيل الضيف. حاليًا، الأجهزة الرئيسية التي تدعم المحاكاة الافتراضية للأجهزة هي المعالجات.
المحاكاة الافتراضية. الخيار الأكثر شيوعًا للمحاكاة الافتراضية للجهاز على KVM وبشكل عام هو وضع المحاكاة الافتراضية الأكثر شيوعًا لأنظمة التشغيل الضيف. تكمن خصوصيته في أن العمل مع بعض الأنظمة الفرعية لبرنامج Hypervisor (على سبيل المثال، مع الشبكة أو مكدس القرص) أو تخصيص صفحات الذاكرة يحدث باستخدام واجهة برمجة تطبيقات Hypervisor، دون ترجمة الأوامر ذات المستوى المنخفض. عيب طريقة المحاكاة الافتراضية هذه هو أنه يجب تعديل نواة نظام التشغيل الضيف حتى تتمكن من التواصل مع برنامج Hypervisor باستخدام واجهة برمجة التطبيقات هذه. ولكن يتم حل هذه المشكلة عادةً عن طريق تثبيت برامج تشغيل خاصة على نظام التشغيل الضيف. في KVM يسمى API هذا .
مع المحاكاة الافتراضية، مقارنة بالبث، يتم تقليل المسار إلى الجهاز الفعلي بشكل كبير عن طريق إرسال الأوامر مباشرة من الجهاز الظاهري إلى عملية برنامج Hypervisor على المضيف. يتيح لك ذلك تسريع تنفيذ جميع التعليمات داخل الجهاز الظاهري. في KVM، يتم ذلك عن طريق واجهة برمجة تطبيقات Virtio، والتي تعمل فقط مع أجهزة معينة، مثل محول الشبكة أو القرص. هذا هو السبب وراء تثبيت برامج تشغيل Virtio داخل الأجهزة الافتراضية.
الجانب السلبي لهذا التسريع هو أنه ليست كل العمليات التي يتم تشغيلها داخل الجهاز الظاهري تبقى بداخله. يؤدي هذا إلى إنشاء بعض المؤثرات الخاصة التي يمكن أن تؤدي إلى النشر عند السرقة. أوصي ببدء دراسة مفصلة لهذه المشكلة مع .
2.3. جدولة "عادلة".
الجهاز الظاهري الموجود على برنامج Hypervisor هو في الواقع عملية عادية تخضع لقوانين الجدولة (توزيع الموارد بين العمليات) في Linux kernel، لذلك دعونا نلقي نظرة فاحصة عليها.
يستخدم Linux ما يسمى CFS، Completely Fair Scholer، والذي أصبح المجدول الافتراضي منذ kernel 2.6.23. لفهم هذه الخوارزمية، يمكنك قراءة بنية Linux Kernel أو الكود المصدري. يتمثل جوهر CFS في توزيع وقت المعالج بين العمليات اعتمادًا على مدة تنفيذها. كلما زاد وقت وحدة المعالجة المركزية (CPU) الذي تتطلبه العملية، قل وقت وحدة المعالجة المركزية (CPU) الذي تتلقاه. وهذا يضمن أن يتم تنفيذ جميع العمليات "بشكل عادل" - بحيث لا تشغل عملية واحدة جميع المعالجات باستمرار، ويمكن أيضًا تنفيذ عمليات أخرى.
في بعض الأحيان يؤدي هذا النموذج إلى أعمال فنية مثيرة للاهتمام. ربما يتذكر مستخدمو Linux منذ فترة طويلة تجميد محرر نص عادي على سطح المكتب أثناء تشغيل تطبيقات كثيفة الاستخدام للموارد مثل المترجم. حدث هذا لأن المهام غير كثيفة الاستخدام للموارد في تطبيقات سطح المكتب تنافست مع المهام كثيفة الاستخدام للموارد، مثل المترجم. تعتقد CFS أن هذا غير عادل، لذلك تقوم بإيقاف محرر النصوص بشكل دوري وتسمح للمعالج بمعالجة مهام المترجم. تم تصحيح هذا باستخدام آلية ولكن بقيت العديد من الميزات الأخرى لتوزيع وقت المعالج بين المهام. في الواقع، هذه ليست قصة عن مدى سوء كل شيء في CFS، ولكنها محاولة للفت الانتباه إلى حقيقة أن التوزيع "العادل" لوقت المعالج ليس المهمة الأكثر تافهة.
نقطة أخرى مهمة في المجدول هي الشفعة. يعد هذا ضروريًا لطرد عملية الضحك من المعالج والسماح للآخرين بالعمل. تسمى عملية الإخراج بتبديل السياق. في هذه الحالة، يتم الحفاظ على سياق المهمة بالكامل: حالة المكدس، والسجلات، وما إلى ذلك، وبعد ذلك يتم إرسال العملية للانتظار، وتأخذ عملية أخرى مكانها. تعد هذه عملية مكلفة لنظام التشغيل ونادرًا ما يتم استخدامها، ولكن لا يوجد بها أي خطأ بطبيعتها. قد يشير التبديل المتكرر للسياق إلى وجود مشكلة في نظام التشغيل، ولكنه عادةً ما يكون مستمرًا ولا يشير إلى أي شيء محدد.
هناك حاجة إلى مثل هذه القصة الطويلة لشرح حقيقة واحدة: كلما زادت موارد المعالج التي تحاول العملية استهلاكها في برنامج جدولة Linux صادق، كلما تم إيقافها بشكل أسرع حتى تتمكن العمليات الأخرى من العمل أيضًا. ما إذا كان هذا صحيحًا أم لا هو سؤال معقد يمكن حله بشكل مختلف تحت أحمال مختلفة. في نظام التشغيل Windows، حتى وقت قريب، كان المجدول يركز على المعالجة ذات الأولوية لتطبيقات سطح المكتب، مما قد يتسبب في تجميد العمليات الخلفية. كان لدى Sun Solaris خمس فئات مختلفة من المجدولين. عندما أطلقنا المحاكاة الافتراضية، أضفنا واحدة سادسة، ، لأن الخمسة السابقة لم تعمل بشكل مناسب مع المحاكاة الافتراضية لـ Solaris Zones. أوصي ببدء دراسة مفصلة لهذه المشكلة بكتب مثل أو .
2.4. كيفية مراقبة السرقة؟
تعد مراقبة السرقة داخل جهاز افتراضي، مثل أي مقياس آخر للمعالج، أمرًا بسيطًا: يمكنك استخدام أي أداة لقياس المعالج. الشيء الرئيسي هو أن الجهاز الظاهري يعمل بنظام Linux. لسبب ما، لا يوفر Windows هذه المعلومات لمستخدميه. 🙁
إخراج الأمر العلوي: تفاصيل تحميل المعالج، في العمود الموجود في أقصى اليمين - سرقة
تنشأ الصعوبة عند محاولة الحصول على هذه المعلومات من برنامج Hypervisor. يمكنك محاولة التنبؤ بالسرقة على الجهاز المضيف، على سبيل المثال، باستخدام معلمة متوسط التحميل (LA) - القيمة المتوسطة لعدد العمليات المنتظرة في قائمة انتظار التنفيذ. طريقة حساب هذه المعلمة ليست بسيطة، ولكن بشكل عام، إذا كانت LA التي تم تطبيعها بواسطة عدد مؤشرات ترابط المعالج أكثر من 1، فهذا يشير إلى أن خادم Linux مثقل بشيء ما.
ماذا تنتظر كل هذه العمليات؟ الجواب الواضح هو المعالج. لكن الإجابة ليست صحيحة تماما، لأنه في بعض الأحيان يكون المعالج مجانيا، لكن LA يخرج عن النطاق. يتذكر . يمكن أن يحدث الشيء نفسه مع القرص وأجهزة الإدخال/الإخراج الأخرى. ولكن في الواقع، يمكن للعمليات الانتظار حتى نهاية أي قفل، سواء كان فعليًا، مرتبطًا بجهاز الإدخال/الإخراج، أو منطقيًا، مثل كائن المزامنة (mutex). يتضمن هذا أيضًا القفل على مستوى الأجهزة (نفس الاستجابة من القرص)، أو المنطق (ما يسمى بأساسيات القفل، والتي تتضمن مجموعة من الكيانات، كائن المزامنة التكيفي والتدوير، الإشارات، متغيرات الحالة، أقفال rw، أقفال ipc ...).
ميزة أخرى لـ LA هي أنها تعتبر متوسط نظام التشغيل. على سبيل المثال، تتنافس 100 عملية على ملف واحد، ومن ثم LA=50. يبدو أن هذه القيمة الكبيرة تشير إلى أن نظام التشغيل سيء. ولكن بالنسبة إلى التعليمات البرمجية الأخرى المكتوبة بشكل ملتوي، قد تكون هذه حالة طبيعية، على الرغم من أنها سيئة فقط، ولا تعاني العمليات الأخرى في نظام التشغيل.
وبسبب هذا المتوسط (وفي ما لا يقل عن دقيقة)، فإن تحديد أي شيء من خلال مؤشر LA ليس المهمة الأكثر مكافأة، مع نتائج غير مؤكدة للغاية في حالات محددة. إذا حاولت معرفة ذلك، فستجد أن المقالات الموجودة على ويكيبيديا والموارد الأخرى المتاحة تصف فقط الحالات البسيطة، دون شرح عميق للعملية. وأرسل مرة أخرى إلى كل من يهمه الأمر، - اتبع الروابط أدناه. من هو كسول جدًا في التحدث باللغة الإنجليزية - .
3. المؤثرات الخاصة
الآن دعونا نلقي نظرة على حالات السرقة الرئيسية التي واجهناها. سأخبرك كيف يتبعون كل ما سبق وكيف يرتبطون بالمؤشرات الموجودة على برنامج Hypervisor.
إعادة التدوير. الأبسط والأكثر شيوعًا: تمت إعادة استخدام برنامج Hypervisor. في الواقع، هناك الكثير من الأجهزة الافتراضية قيد التشغيل، والاستهلاك العالي للمعالج بداخلها، والكثير من المنافسة، واستخدام LA أكثر من 1 (تم تطبيعه بواسطة سلاسل المعالج). كل شيء داخل جميع الأجهزة الافتراضية يتباطأ. تتزايد أيضًا عمليات السرقة المنقولة من برنامج Hypervisor، ومن الضروري إعادة توزيع الحمل أو إيقاف تشغيل شخص ما. بشكل عام، كل شيء منطقي ومفهوم.
المحاكاة الافتراضية مقابل المثيلات الفردية. يوجد جهاز افتراضي واحد فقط في برنامج Hypervisor، وهو يستهلك جزءًا صغيرًا منه، ولكنه ينتج حمل إدخال/إخراج كبير، على القرص على سبيل المثال. ومن مكان ما تظهر فيه سرقة صغيرة تصل إلى 10٪ (كما أظهرت عدة تجارب).
القضية مثيرة للاهتمام. تظهر السرقة هنا على وجه التحديد بسبب الحظر على مستوى برامج التشغيل شبه الافتراضية. يتم إنشاء المقاطعة داخل الجهاز الظاهري، وتتم معالجتها بواسطة برنامج التشغيل وإرسالها إلى برنامج Hypervisor. نظرًا لمعالجة المقاطعة على برنامج Hypervisor، يبدو الجهاز الظاهري وكأنه طلب مرسل، وهو جاهز للتنفيذ وينتظر المعالج، ولكن لا يتم منحه وقتًا للمعالج. الفتاة الافتراضية تعتقد أن هذه المرة قد سُرقت.
يحدث هذا في لحظة إرسال المخزن المؤقت، وينتقل إلى مساحة kernel لبرنامج Hypervisor، ونبدأ في انتظاره. على الرغم من أنه، من وجهة نظر الجهاز الظاهري، يجب أن يعود على الفور. لذلك، وفقًا لخوارزمية حساب السرقة، تعتبر هذه المرة مسروقة. على الأرجح، في هذه الحالة قد تكون هناك آليات أخرى (على سبيل المثال، معالجة بعض مكالمات النظام الأخرى)، ولكن لا ينبغي أن تكون مختلفة كثيرا.
المجدول مقابل الأجهزة الافتراضية المحملة بشكل كبير. عندما يعاني أحد الأجهزة الافتراضية من السرقة أكثر من الأجهزة الأخرى، فهذا يرجع إلى المجدول. كلما زادت عملية تحميل المعالج، كلما قام المجدول بإخراجها بشكل أسرع حتى يتمكن الآخرون من العمل أيضًا. إذا كانت الآلة الافتراضية تستهلك القليل، فمن الصعب أن تتعرض للسرقة: عمليتها تنتظر وتنتظر بصدق، ونحن بحاجة إلى منحها المزيد من الوقت. إذا كان الجهاز الظاهري ينتج الحد الأقصى من الحمل على جميع مراكزه، فغالبا ما يتم طرده من المعالج ويحاولون عدم منحه الكثير من الوقت.
والأمر الأسوأ هو أن العمليات داخل الجهاز الظاهري تحاول الحصول على المزيد من المعالجات لأنها لا تستطيع التعامل مع معالجة البيانات. بعد ذلك، سيوفر نظام التشغيل الموجود على برنامج Hypervisor، بفضل التحسين الصادق، وقتا أقل وأقل للمعالج. تحدث هذه العملية مثل الانهيار الجليدي، وتقفز بسرعة إلى السماء، على الرغم من أن الأجهزة الافتراضية الأخرى قد لا تلاحظ ذلك بصعوبة. وكلما زاد عدد النوى، كلما كان الجهاز المتأثر أسوأ. باختصار، الأجهزة الافتراضية المحملة بشكل كبير والتي تحتوي على العديد من النوى هي الأكثر معاناة.
انخفاض LA، ولكن هناك سرقة. إذا كان LA حوالي 0,7 (أي يبدو أن برنامج Hypervisor قد تم تنزيله بشكل ناقص)، ولكن تمت ملاحظة السرقة داخل الأجهزة الافتراضية الفردية:
- خيار المحاكاة الافتراضية الموصوف بالفعل أعلاه. يمكن للجهاز الظاهري تلقي مقاييس تشير إلى السرقة، على الرغم من أن برنامج Hypervisor يعمل بشكل جيد. وفقًا لنتائج تجاربنا، فإن خيار السرقة هذا لا يتجاوز 10% ويجب ألا يكون له تأثير كبير على أداء التطبيقات داخل الجهاز الظاهري.
- يتم حساب المعلمة LA بشكل غير صحيح. بتعبير أدق، في كل لحظة محددة يتم حسابها بشكل صحيح، ولكن عندما يتم حسابها في المتوسط لمدة دقيقة واحدة، يتبين أنه تم التقليل من شأنها. على سبيل المثال، إذا كان جهاز افتراضي واحد لكل ثلث برنامج Hypervisor يستهلك جميع معالجاته لمدة نصف دقيقة بالضبط، فإن معدل LA لكل دقيقة على برنامج Hypervisor سيكون 0,15؛ أربعة من هذه الأجهزة الافتراضية التي تعمل في وقت واحد ستعطي 0,6. وحقيقة أنه لمدة نصف دقيقة كان هناك سرقة جامحة لكل منهم بنسبة 25٪ وفقًا لمؤشر LA لم يعد من الممكن سحبها.
- مرة أخرى، بسبب المجدول الذي قرر أن شخصًا ما كان يأكل أكثر من اللازم وتركه ينتظر. في هذه الأثناء، سأقوم بتبديل السياق، والتعامل مع المقاطعات، والاعتناء بأمور النظام المهمة الأخرى. ونتيجة لذلك، فإن بعض الأجهزة الافتراضية لا ترى أية مشكلات، بينما تواجه أجهزة أخرى تدهورًا خطيرًا في الأداء.
4. التشوهات الأخرى
هناك مليون سبب آخر لتشويه العائد العادل لوقت المعالج على جهاز افتراضي. على سبيل المثال، يؤدي كل من Hyperthreading وNUMA إلى صعوبات في العمليات الحسابية. إنهم يخلطون تماما بين اختيار النواة لتنفيذ العملية، لأن المجدول يستخدم المعاملات - الأوزان، التي تجعل الحساب أكثر صعوبة عند تبديل السياق.
هناك تشوهات بسبب تقنيات مثل Turbo Boost أو، على العكس من ذلك، وضع توفير الطاقة، والتي، عند حساب الاستخدام، يمكن أن تزيد أو تقلل بشكل مصطنع التردد أو حتى شريحة الوقت على الخادم. يؤدي تمكين التعزيز التوربيني إلى تقليل أداء أحد سلاسل المعالج بسبب زيادة أداء معالج آخر. في هذه اللحظة، لا يتم نقل المعلومات المتعلقة بتردد المعالج الحالي إلى الجهاز الظاهري، ويعتقد أن شخصًا ما يسرق وقته (على سبيل المثال، طلب 2 جيجا هرتز، لكنه حصل على نصف ذلك).
بشكل عام، يمكن أن يكون هناك أسباب كثيرة للتشويه. قد تجد شيئا آخر على نظام معين. من الأفضل أن تبدأ بالكتب التي أعطيت روابط لها أعلاه، واسترداد الإحصائيات من برنامج Hypervisor باستخدام أدوات مساعدة مثل perf، وsysdig، وsystemtap، والتي منها .
5 - نتائج
- قد يحدث قدر من السرقة بسبب المحاكاة الافتراضية، ويمكن اعتباره أمرًا طبيعيًا. يكتبون على الإنترنت أن هذه القيمة يمكن أن تكون 5-10٪. يعتمد على التطبيقات الموجودة داخل الجهاز الظاهري وعلى الحمل الذي يضعه على أجهزته الفعلية. من المهم هنا الانتباه إلى كيفية عمل التطبيقات داخل الأجهزة الافتراضية.
- لا تكون دائمًا نسبة الحمل على برنامج Hypervisor والسرقة داخل الجهاز الظاهري مترابطة بشكل واضح؛ يمكن أن يكون كلا تقديري السرقة خاطئين في مواقف محددة تحت أحمال مختلفة.
- لدى المجدول موقف سيء تجاه العمليات التي تتطلب الكثير. يحاول أن يعطي أقل لمن يطلب المزيد. الآلات الافتراضية الكبيرة شريرة.
- يمكن أن تكون السرقة الصغيرة هي القاعدة حتى بدون استخدام المحاكاة الافتراضية (مع الأخذ في الاعتبار الحمل داخل الجهاز الظاهري، وخصائص حمل الجيران، وتوزيع الحمل عبر الخيوط وعوامل أخرى).
- إذا كنت تريد اكتشاف السرقة في نظام معين، فيجب عليك استكشاف الخيارات المختلفة، وجمع المقاييس، وتحليلها بعناية والتفكير في كيفية توزيع الحمل بالتساوي. من الممكن حدوث انحرافات عن أي حالة، والتي يجب تأكيدها تجريبيًا أو النظر فيها في مصحح أخطاء kernel.
المصدر: www.habr.com