من يسرق وقت وحدة المعالجة المركزية الافتراضية؟

مرحبا! في هذه المقالة ، أود أن أشرح ، بعبارات للشخص العادي ، كيف تظهر السرقة في VMs وأن أخبركم ببعض القطع الأثرية الأقل وضوحًا التي وجدناها أثناء البحث عن الموضوع الذي شاركت فيه بصفتي CTO of the Mail. كوم حلول سحابة منصة. تعمل المنصة KVM.

وحدة المعالجة المركزية سرقة الوقت هو الوقت الذي لا يتلقى فيه جهاز VM الموارد اللازمة للعمل. لا يمكن حساب هذه المرة إلا في نظام التشغيل الضيف في البيئات الافتراضية. من غير الواضح للغاية أين تضيع الموارد المخصصة ، كما هو الحال في مواقف الحياة الحقيقية. ومع ذلك ، قررنا معرفة ذلك ، وقمنا بإجراء سلسلة من الاختبارات للقيام بذلك. هذا لا يعني أننا نعرف كل شيء عن السرقة ، ولكن هناك بعض الأشياء الرائعة التي نود مشاركتها معك.

1. ما هو السرقة ؟

السرقة عبارة عن مقياس يشير إلى نقص وقت وحدة المعالجة المركزية لعمليات VM. كما هو موضح في تصحيح KVM kernel ، فإن السرقة هو الوقت الذي يقضي فيه برنامج hypervisor في تشغيل العمليات الأخرى في نظام تشغيل مضيف ، بينما تكون عملية VM في قائمة انتظار التشغيل. بمعنى آخر ، يتم حساب السرقة على أنها الفرق بين اللحظة التي تكون فيها العملية جاهزة للتشغيل واللحظة التي يتم فيها تخصيص وقت وحدة المعالجة المركزية للعملية.

تحصل نواة VM على مقياس السرقة من برنامج Hypervisor. لا يحدد برنامج hypervisor العمليات التي يعمل بها. تقول فقط: "أنا مشغول ولا يمكنني تخصيص أي وقت لك." في KVM ، يتم دعم حساب السرقة في التصحيحات . هناك نقطتان رئيسيتان بخصوص هذا:

• تعرف VM على السرقة من برنامج Hypervisor. هذا يعني أنه من حيث الخسائر ، السرقة مقياس غير مباشر يمكن تشويهه بعدة طرق.
  
• لا يشارك برنامج Hypervisor مع معلومات VM فيما يتعلق بما يشغله. النقطة الأكثر أهمية هي أنها لا تخصص الوقت لها. وبالتالي ، لا يمكن لـ VM نفسها اكتشاف التشوهات في مقياس السرقة ، والتي يمكن تقديرها حسب طبيعة العمليات المتنافسة.
  

2. ما يؤثر على السرقة ؟

2.1. حساب سرقة

بشكل أساسي ، يتم حساب السرقة بطريقة أو بأخرى بنفس طريقة استخدام وحدة المعالجة المركزية. لا يوجد قدر كبير من المعلومات المتعلقة بكيفية حساب الاستخدام. هذا ربما لأن معظم المهنيين يعتقدون أنه واضح. ومع ذلك ، هناك بعض المزالق. تم وصف العملية في مقال بقلم بريندان جريج . يناقش مجموعة كاملة من الفروق الدقيقة فيما يتعلق بكيفية حساب الاستخدام والسيناريوهات التي سيكون فيها الحساب خاطئًا:

• وحدة المعالجة المركزية المحموم والاختناق.
  
• تشغيل / إيقاف تشغيل Turbo Boost ، مما يؤدي إلى تغيير في معدل ساعة وحدة المعالجة المركزية.
• تغيير شريحة الوقت الذي يحدث عند استخدام تقنيات توفير الطاقة لوحدة المعالجة المركزية ، مثل SpeedStep.
  
• المشاكل المتعلقة بحساب المتوسطات: قياس الاستخدام لمدة دقيقة واحدة عند 80 ٪ من الطاقة يمكن أن يخفي زيادة قصيرة الأجل بنسبة 100 ٪.
  
• spinlock ينتج عنه سيناريو يتم فيه استخدام المعالج ، لكن عملية المستخدم لا تتقدم. نتيجة لذلك ، سيكون استخدام وحدة المعالجة المركزية المحسوبة 100٪ ، لكن العملية لن تستهلك فعليًا وقت وحدة المعالجة المركزية.
  

لم أصادف أي مقالات تصف حسابات السرقة هذه (إذا كنت تعرف أي منها ، يرجى مشاركتها في قسم التعليقات). كما ترى من الكود المصدري ، فإن آلية الحساب هي نفسها للاستخدام. الفرق الوحيد هو أنه يتم إضافة عداد آخر على وجه التحديد لعملية KVM (عملية VM) ، والتي تحسب كم من الوقت كانت عملية KVM تنتظر وقت وحدة المعالجة المركزية. يأخذ العداد البيانات على وحدة المعالجة المركزية من مواصفاته ويتحقق مما إذا كان يتم استخدام كافة علامات التجزئة بواسطة عملية VM. إذا تم استخدام كافة علامات التجزئة ، فكانت وحدة المعالجة المركزية مشغولة فقط بعملية VM. خلاف ذلك ، نحن نعلم أن وحدة المعالجة المركزية كانت تفعل شيئًا آخر وتظهر سرقة .

تخضع العملية التي يتم بها حساب السرقة لنفس مشكلات الحساب المنتظم للاستخدام. هذه المشكلات ليست شائعة ، ولكنها قد تبدو مربكة إلى حد ما.

2.2. أنواع KVM الافتراضية

بشكل عام ، هناك ثلاثة أنواع من المحاكاة الافتراضية ، وكلها مدعومة بواسطة KVM. قد تعتمد الآلية التي يحدث بها السرقة على نوع المحاكاة الافتراضية.

الترجمة. في هذه الحالة ، سيعمل VM OS مع أجهزة برنامج Hypervisor الفعلية بالطريقة التالية:

1. يقوم نظام التشغيل الضيف بإرسال أمر إلى جهاز الضيف الخاص به.
   
2. يقبل برنامج تشغيل جهاز الضيف الأمر ، ويقوم بإنشاء طلب جهاز BIOS ، ويرسل الأمر إلى برنامج Hypervisor.
   
3. تقوم عملية برنامج Hypervisor بترجمة الأمر إلى أمر جهاز فعلي ، مما يجعله أكثر أمانًا ، من بين أشياء أخرى.
   
4. يقبل برنامج تشغيل الجهاز الفعلي الأمر المعدل ويعيد توجيهه إلى الجهاز الفعلي نفسه.
   
5. إرجاع نتائج تنفيذ الأمر باتباع نفس المسار.
   

تكمن ميزة الترجمة في أنها تتيح لنا محاكاة أي جهاز ولا يتطلب أي إعداد خاص لنظام التشغيل OS kernel. ولكن هذا يأتي على حساب الأداء.

الأجهزة الافتراضية. في هذه الحالة ، يتلقى الجهاز أوامر من نظام التشغيل على مستوى الجهاز. هذا هو أسرع وأفضل طريقة شاملة. لسوء الحظ ، لا تدعمها جميع الأجهزة المادية وبرامج Hypervisor وأجهزة الضيف. في الوقت الحالي ، تعد الأجهزة الرئيسية التي تدعم محاكاة الأجهزة الافتراضية هي وحدات المعالجة المركزية (CPU).

الظاهرية الافتراضية. الخيار الأكثر شيوعًا للمحاكاة الافتراضية للجهاز على KVM والنوع الأكثر انتشارًا من المحاكاة الافتراضية لأنظمة التشغيل الضيف. الميزة الرئيسية هي أنه يعمل مع بعض النظم الفرعية لبرنامج Hypervisor (مثل شبكة أو مجموعة محركات أقراص) وتخصص صفحات الذاكرة باستخدام API hypervisor دون ترجمة الأوامر ذات المستوى المنخفض. عيب هذه الطريقة الافتراضية هو الحاجة إلى تعديل نواة نظام التشغيل الضيف للسماح للتفاعل مع برنامج hypervisor باستخدام نفس API. الحل الأكثر شيوعًا لهذه المشكلة هو تثبيت برامج تشغيل خاصة في نظام التشغيل الضيف. في KVM ، يُطلق على واجهة برمجة التطبيقات API API .

عند استخدام paravirtualization ، يكون المسار إلى الجهاز الفعلي أقصر بكثير من الحالات التي يتم فيها استخدام الترجمة ، لأن الأوامر يتم إرسالها مباشرة من VM إلى عملية hypervisor في المضيف. هذا يسرع تنفيذ جميع التعليمات داخل VM. في KVM ، مسؤول API هو المسؤول عن هذا. يعمل فقط مع بعض الأجهزة مثل محولات الشبكة ومحركات الأقراص. هذا هو السبب في أن يتم تثبيت برامج التشغيل الفعلية على VMs.

الجانب الآخر من مثل هذا التسارع هو أنه ليست كل العمليات المنفذة في VM تبقى داخل VM. هذا يؤدي إلى عدد من الآثار ، والتي قد تسبب سرقة . إذا كنت ترغب في معرفة المزيد ، فابدأ باستخدام واجهة برمجة تطبيقات (API) للإدخال / الإخراج الظاهري: virtio .

2.3. جدولة عادلة

VM على برنامج hypervisor ، في الواقع ، عملية منتظمة ، والتي تخضع لقوانين الجدولة (توزيع الموارد بين العمليات) في نواة Linux. دعونا نلقي نظرة فاحصة على هذا.

يستخدم نظام Linux ما يسمى CFS ، برنامج الجدولة العادلة تمامًا ، والذي أصبح الافتراضي مع kernel 2.6.23. للحصول على التعامل مع هذه الخوارزمية ، اقرأ Linux Kernel Architecture أو الكود المصدر. يكمن جوهر CFS في توزيع وقت وحدة المعالجة المركزية بين العمليات ، اعتمادًا على وقت التشغيل. كلما زاد وقت وحدة المعالجة المركزية التي تتطلبها العملية ، قلت مدة وحدة المعالجة المركزية. هذا يضمن التنفيذ "العادل" لجميع العمليات ويساعد على تجنب عملية واحدة تستوعب جميع المعالجات ، في جميع الأوقات ، ويسمح للعمليات الأخرى بالعمل أيضًا.

في بعض الأحيان يؤدي هذا النموذج إلى تحف فنية مثيرة للاهتمام. مما لا شك فيه أن مستخدمي Linux القدامى سيتذكرون كيف سيتجمد محرر النصوص العادي على سطح المكتب عند تشغيل تطبيقات كثيفة الاستخدام للموارد مثل برنامج التحويل البرمجي. حدث هذا لأن مهام ضوء الموارد ، مثل تطبيقات سطح المكتب ، كانت تتنافس مع المهام التي تستخدم العديد من الموارد ، مثل برنامج التحويل البرمجي. يعتبر CFS هذا غير عادل ، ولذا فهو يتوقف محرر النصوص من وقت لآخر ويسمح لوحدة المعالجة المركزية بمعالجة مهام برنامج التحويل البرمجي. تم إصلاح هذا باستخدام آلية sched_autogroup ؛ هناك ، مع ذلك ، العديد من الخصائص الأخرى لتوزيع وقت وحدة المعالجة المركزية. هذه المقالة ليست في الحقيقة حول مدى سوء CFS. إنها بالأحرى محاولة للفت الانتباه إلى حقيقة أن التوزيع "العادل" لوقت وحدة المعالجة المركزية ليس المهمة الأكثر تافهة.

جانب هام آخر لجدولة هو الاستباق. هذا ضروري لتخليص وحدة المعالجة المركزية من أي عمليات مفرطة الانغماس والسماح للآخرين بالعمل أيضًا. وهذا ما يسمى تبديل السياق . يتم الاحتفاظ بسياق المهمة بالكامل: حالة المكدس ، والسجلات ، وما إلى ذلك ، وبعد ذلك يتم ترك العملية في الانتظار واستبدالها بعملية أخرى. هذه عملية مكلفة لنظام التشغيل. نادراً ما يستخدم ، لكنه في الواقع ليس سيئاً على الإطلاق. قد يكون التبديل المتكرر للسياق مؤشراً لمشكلة نظام التشغيل ، ولكنه يحدث عادة بشكل مستمر ولا يمثل علامة على أي مشكلة على وجه الخصوص.

كان هذا الخطاب الطويل ضروريًا لشرح حقيقة واحدة: في برنامج جدولة Linux العادل ، كلما زادت موارد وحدة المعالجة المركزية التي تستهلكها العملية ، كلما تم إيقافها بشكل أسرع للسماح لعمليات أخرى بالعمل. إذا كان هذا صحيحًا أم لا ، فهو سؤال معقد ، والحل مختلف اعتمادًا على الحمل. حتى وقت قريب ، أعطت جدولة Windows أولوية تطبيقات سطح المكتب ، مما أدى إلى عمليات أبطأ في الخلفية. في Sun Solaris كان هناك خمسة فصول جدولة مختلفة. عند تقديم المحاكاة الافتراضية ، أضافوا واحدًا آخر ، هو برنامج جدولة المشاركة العادلة ، لأن الآخرين لم يعملوا بشكل صحيح باستخدام تقنية Solaris Zones الافتراضية. للتعمق في هذا الأمر ، أوصي بالبدء باستخدام Solaris Internals: Solaris 10 و OpenSolaris Kernel Architecture أو Understanding the Linux Kernel .

2.4. كيف يمكننا مراقبة السرقة ؟

تمامًا مثل أي مقياس CPU آخر ، من السهل مراقبة السرقة داخل جهاز VM. يمكنك استخدام أي أداة قياس متري وحدة المعالجة المركزية. الشيء الرئيسي هو أن VM يجب أن يكون على Linux. لسبب ما ، لا يوفر Windows هذه المعلومات للمستخدم. :(


أعلى الإخراج: مواصفات تحميل وحدة المعالجة المركزية مع سرقة في العمود الأيمن

تصبح الأمور معقدة عند محاولة الحصول على هذه المعلومات من برنامج Hypervisor. يمكنك محاولة التنبؤ بالسرقة على جهاز مضيف ، باستخدام Load Average (LA) ، على سبيل المثال. هذا هو متوسط ​​قيمة عدد العمليات في قائمة انتظار التشغيل. طريقة الحساب لهذه المعلمة ليست طريقة بسيطة ، ولكن بشكل عام ، إذا كانت LA التي تم توحيدها وفقًا لعدد مؤشرات ترابط وحدة المعالجة المركزية أكبر من 1 ، فهذا يعني أن خادم Linux محمّل بشكل زائد.

فما هي كل هذه العمليات في انتظار؟ من الواضح ، وحدة المعالجة المركزية. هذه الإجابة ليست دقيقة تمامًا ، لأنه في بعض الأحيان تكون وحدة المعالجة المركزية مجانية ولوس أنجليس مرتفعة للغاية. تذكر أن NFS يسقط وترتفع LA في نفس الوقت . قد يحدث موقف مماثل مع محرك الأقراص وأجهزة الإدخال / الإخراج الأخرى. في الواقع ، قد تنتظر العمليات نهاية القفل: فعلي (يتعلق بأجهزة الإدخال / الإخراج) أو منطقي (كائن كائن مزامنة ، على سبيل المثال). وينطبق الشيء نفسه على الأقفال على مستوى الأجهزة (على سبيل المثال ، استجابة القرص) أو الأقفال على مستوى المنطق (ما يسمى "بدائل التأمين" ، والتي تشمل عددًا من الكيانات ، mutex adaptive و spin ، و semaphores ، ومتغيرات الحالة ، وأقفال rw ، أقفال ipc ...).

ميزة أخرى من لوس أنجلوس هي أنه يتم حسابها كقيمة متوسطة داخل نظام التشغيل. على سبيل المثال ، إذا كانت هناك 100 عملية تتنافس على ملف واحد ، فإن LA هي 50. قد يجعل هذا العدد الكبير يبدو كأنه أمر سيء لنظام التشغيل. ومع ذلك ، لرمز مكتوب بشكل سيء يمكن أن يكون هذا طبيعي. سيكون هذا الرمز المحدد فقط سيئًا ، وقد يكون باقي نظام التشغيل جيدًا.

بسبب هذا المتوسط ​​(لمدة تقل عن دقيقة واحدة) ، فإن تحديد أي شيء باستخدام LA ليس هو أفضل فكرة ، لأنه يمكن أن يؤدي إلى نتائج غامضة للغاية في بعض الحالات. إذا حاولت معرفة المزيد حول هذا الموضوع ، فستجد أن ويكيبيديا وغيرها من الموارد المتاحة تصف فقط أبسط الحالات ، ولم يتم وصف العملية بالتفصيل. إذا كنت مهتمًا بهذا ، مرة أخرى ، فقم بزيارة Brendann Gregg واتبع الروابط.

3. المؤثرات الخاصة

الآن دعنا نصل إلى الحالات الرئيسية للسرقة التي واجهناها. اسمحوا لي أن أشرح كيف تنتج عن ما ورد أعلاه وكيف ترتبط مع مقاييس برنامج Hypervisor.

Overutilization. أبسط الحالات وأكثرها شيوعًا: الإفراط في استخدام برنامج Hypervisor. في الواقع ، مع وجود الكثير من VMs التي تعمل وتستهلك الكثير من موارد وحدة المعالجة المركزية ، تكون المنافسة عالية ، والاستخدام وفقًا لقانون LA أكبر من 1 (موحد وفقًا لخيوط CPU). كل شيء يتخلف داخل جميع VMs. سرقة المرسلة من hypervisor ينمو كذلك. يجب عليك إعادة توزيع التحميل أو إيقاف تشغيل شيء ما. على العموم ، هذا كل شيء منطقي ومباشر.

Paravirtualization مقابل مثيلات مفردة. يوجد جهاز VM واحد فقط على برنامج hypervisor. يستهلك جهاز VM جزءًا صغيرًا منه ، لكنه يوفر حمولة إدخال / إخراج عالية ، على سبيل المثال ، لمحرك أقراص. بشكل غير متوقع ، تظهر سرقة صغيرة تقل عن 10٪ (كما تظهر بعض الاختبارات التي أجريناها).

هذه قضية غريبة. هنا ، تظهر السرقة بسبب وجود أقفال على مستوى الأجهزة الافتراضية. داخل VM ، يتم إنشاء نقطة توقف. تتم معالجة هذا بواسطة برنامج التشغيل ويذهب إلى برنامج hypervisor. نظرًا لمعالجة نقطة التوقف على برنامج hypervisor ، يرى VM هذا كطلب مرسَل. إنه جاهز للتشغيل وينتظر وحدة المعالجة المركزية ، لكن لا يتلقى أي وقت من وحدة المعالجة المركزية. يعتقد VM أن الوقت قد سُرق.

يحدث هذا عندما يتم إرسال المخزن المؤقت. يذهب إلى مساحة نواة برنامج Hypervisor وننتظرها. من وجهة نظر VM ، يجب أن يعود على الفور. لذلك ، وفقًا لخوارزمية حساب السرقة لدينا ، تعتبر هذه المرة مسروقة. من المحتمل أن تشارك آليات أخرى في هذا (على سبيل المثال معالجة مكالمات sys الأخرى) ، لكن لا ينبغي أن تختلف إلى حد كبير.

جدولة مقابل VMs محملة للغاية. عندما يعاني أحد VM من السرقة أكثر من الآخر ، فهذا مرتبط مباشرةً بجدول المواعيد. كلما زاد الحمل الذي تضعه العملية على وحدة المعالجة المركزية ، كلما أسرع برنامج الجدولة في التخلص منه ، وذلك للسماح للعمليات الأخرى بالعمل. إذا كان جهاز VM يستهلك القليل ، فلن يواجه أي سرقة تقريبًا . عمليتها كانت جالسة وتنتظر فقط ، ويجب منحها مزيدًا من الوقت. إذا وضعت VM حمولة قصوى على جميع النوى ، يتم إلقاء العملية في كثير من الأحيان ويتم منح VM وقتًا أقل.

يكون الأمر أسوأ عندما تحاول العمليات داخل جهاز VM الحصول على مزيد من وحدة المعالجة المركزية ، لأنها لا تستطيع معالجة البيانات. ثم يوفر نظام التشغيل الموجود على برنامج hypervisor وقتًا أقل لوحدة المعالجة المركزية بسبب التحسين العادل. هذه العملية كرات الثلج ، وسرقة ارتفاع السماء ، في حين أن أجهزة الرصد الأخرى قد لا تلاحظ ذلك. لمزيد من النوى هناك ، والأسوأ من ذلك هو ل VM المؤسف. باختصار ، تعاني VMs المحملة بدرجة عالية والتي تحتوي على العديد من النوى أكثر من غيرها.

انخفاض LA ولكن سرقة موجود. إذا كانت LA حوالي 0.7 (مما يعني أن برنامج Hypervisor يبدو أقل من طاقته) ، ولكن هناك سرقة في بعض أجهزة VM:

• ينطبق المثال الافتراضي المذكور أعلاه. قد تتلقى VM مقاييس تشير إلى السرقة ، في حين أن برنامج Hypervisor لا يواجه أية مشكلات. وفقًا لنتائج اختباراتنا ، لا تميل هذه السرقة إلى 10٪ ولا يكون لها تأثير كبير على أداء التطبيق داخل جهاز VM.
  
• تم حساب المعلمة LA بشكل غير صحيح. بتعبير أدق ، تم حسابه بشكل صحيح في لحظة محددة ، ولكن عند حساب المتوسط ​​، يكون أقل مما يجب أن يكون لمدة دقيقة واحدة. على سبيل المثال ، إذا استهلك جهاز VM (ثلث المشرف) جميع وحدات المعالجة المركزية (CPU) لمدة 30 ثانية ، فسيكون LA لمدة دقيقة 0.15. أربعة من هذه الأجهزة ، التي تعمل في نفس الوقت ، ستؤدي إلى قيمة 0.6. استنادًا إلى LA ، لن تتمكن من استنتاج أنه لمدة 30 ثانية لكل منهم ، كانت السرقة تقارب 25٪.
  
• مرة أخرى ، حدث هذا بسبب الجدولة ، التي قررت أن شخصًا ما "يأكل" أكثر من اللازم ويجعلهم ينتظرون. وفي الوقت نفسه ، فإنه سيتم تبديل السياق ، نقاط التوقف العملية ، والحضور إلى مسائل النظام الهامة الأخرى. نتيجة لذلك ، لا تواجه بعض أجهزة VM أية مشكلات ، بينما يعاني البعض الآخر من خسائر كبيرة في الأداء.
  

4. تشوهات أخرى

هناك مليون الأسباب المحتملة لتشويه تخصيص وقت وحدة المعالجة المركزية عادلة على VM. على سبيل المثال ، يضيف hyperthreading و NUMA التعقيد إلى العمليات الحسابية. أنها تعقد اختيار الأساسية المستخدمة لتشغيل عملية لأن المجدول يستخدم المعاملات. وهذا يعني أن الأوزان ، والتي تعقد العمليات الحسابية أكثر من ذلك عند تبديل السياقات.

هناك تشوهات تنشأ عن تقنيات مثل Turbo Boost أو وضع توفير الطاقة المقابل لها ، مما قد يؤدي إلى زيادة أو تقليل سرعة وحدة المعالجة المركزية بشكل مصطنع وحتى شريحة الوقت. تشغيل Turbo Boost على تقليل إنتاجية مؤشر ترابط وحدة المعالجة المركزية واحد بسبب زيادة الأداء في أخرى. في تلك اللحظة ، لا يتم إرسال المعلومات المتعلقة بسرعة ساعة وحدة المعالجة المركزية الحالية إلى جهاز VM ، والذي يعتقد أن شخصًا ما يسرق وقته (على سبيل المثال ، طلب 2 جيجا هرتز وحصل على نصف ذلك).

في الواقع ، يمكن أن يكون هناك العديد من الأسباب للتشويه. قد تجد شيئا آخر تماما في أي نظام معين. أوصي بالبدء بالكتب المرتبطة أعلاه والحصول على إحصائيات من برنامج hypervisor باستخدام أدوات مثل perf و sysdig و systemtap وعشرات غيرها .

5. الاستنتاجات

1. قد تظهر بعض السرقة بسبب parav افتراضية ويمكن اعتبار هذا طبيعي. تقول المصادر على الإنترنت أن هذه القيمة يمكن أن تكون 5-10 ٪. يعتمد ذلك على التطبيق داخل VM ، والحمل الذي يضعه VM على أجهزته المادية. من المهم الانتباه إلى ما تشعر به التطبيقات داخل جهاز VM.
   
2. العلاقة بين الحمل على برنامج Hypervisor والسرقة داخل جهاز VM غير مؤكدة دائمًا. يمكن أن تكون كلتا الحسابات سرقة خاطئة في بعض الحالات وبأحمال مختلفة.
   
3. لا تفضل المجدول العمليات التي تتطلب الكثير من الموارد. يحاول إعطاء أقل لأولئك الذين يطلبون المزيد. الحالات الكبيرة تعني.
   
4. يمكن للسرقة الصغيرة أن تكون طبيعية دون وجود إفتراضات افتراضية أيضًا (مع الأخذ في الاعتبار الحمل داخل VM ، وخصائص أحمال الجيران ، وتوزيع الحمل بين الخيوط ، وعوامل أخرى).
   
5. إذا كنت ترغب في حساب السرقة في نظام معين ، فابحث في مختلف الاحتمالات ، وجمع المقاييس ، وقم بتحليلها بدقة ، وفكر في كيفية توزيع الحمل بشكل عادل. بغض النظر ، يمكن أن يكون هناك انحرافات ، والتي يجب التحقق منها باستخدام الاختبارات أو عرضها في مصحح أخطاء kernel.