سرقة: من يسرق وقت المعالج من الأجهزة الافتراضية

تحية! أريد أن أخبر بلغة واضحة عن آليات ظهور السرقة داخل الأجهزة الافتراضية وعن بعض القطع الأثرية غير الواضحة التي تمكنا من اكتشافها خلال بحثه ، والتي اضطررت إلى الغوص فيها كمستشار فني لمنصة السحابة Mail.ru Cloud Solutions . تعمل المنصة على KVM.

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

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

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

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

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

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

2.1. حساب سرقة

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

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

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

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

2.2. أنواع المحاكاة الافتراضية على KVM

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

البث. في هذه الحالة ، يحدث تشغيل نظام تشغيل الجهاز الظاهري مع الأجهزة الفعلية لبرنامج hypervisor كالتالي:

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

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

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

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

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

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

2.3. Sheduling عادلة

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

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

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

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

هناك حاجة إلى مثل هذه القصة الطويلة لشرح حقيقة واحدة: فكلما زادت موارد المعالج التي يستهلكها sheduler Linux الصادق ، كلما تم إيقافها بشكل أسرع حتى تعمل العمليات الأخرى أيضًا. سواء كان ذلك صحيحًا أم لا ، فهذه مشكلة معقدة ، يتم حلها بشكل مختلف تحت أحمال مختلفة. في Windows ، حتى وقت قريب ، كان sheduler يركز على المعالجة ذات الأولوية لتطبيقات سطح المكتب ، بسبب العمليات الخلفية التي يمكن تعليقها. كان صن سولاريس خمس فئات مختلفة من shedulers. عند بدء المحاكاة الافتراضية ، أضافوا جدولة المشاركة العادلة السادسة ، نظرًا لأن الخمسة السابقة عملت مع Virtual Solar Zones virtualization بشكل غير كافٍ. أوصي ببدء دراسة مفصلة لهذه المشكلة مع كتب مثل Solaris Internals: Solaris 10 و OpenSolaris Kernel Architecture أو Understanding the Linux Kernel .

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

مراقبة السرقة داخل جهاز افتراضي ، مثل أي مقياس للمعالج ، أمر بسيط: يمكنك استخدام أي وسيلة لإزالة مقاييس المعالج. الشيء الرئيسي هو أن الجهاز الظاهري هو على لينكس. لسبب ما ، لا يوفر Windows مثل هذه المعلومات لمستخدميه. :(


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

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

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

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

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

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

الآن دعونا نتحدث عن حالات السرقة الرئيسية التي واجهناها. سوف أخبركم كيف يتبعون ما تقدم وكيف يرتبطون بالمؤشرات على برنامج hypervisor.

إعادة التدوير . أبسط وأكثرها تكرارا: إعادة استخدام برنامج Hypervisor. في الواقع ، هناك الكثير من الأجهزة الظاهرية التي تعمل ، واستهلاك كبير للمعالج بداخلها ، والكثير من المنافسة ، واستخدام LA أكثر من 1 (تم تطبيعه بواسطة مؤشرات ترابط المعالج). داخل كل virtualoks كل شيء يبطئ. تتزايد السرقة المنقولة من برنامج hypervisor أيضًا ، فمن الضروري إعادة توزيع الحمل أو إيقاف تشغيل شخص ما. بشكل عام ، كل شيء منطقي ومفهوم.

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

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

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

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

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

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

• الخيار الموضح أعلاه مع parav افتراضية. يمكن للجهاز الظاهري استلام مقاييس تشير إلى السرقة ، على الرغم من أن كل شيء على ما يرام مع برنامج Hypervisor. وفقًا لنتائج تجاربنا ، لا يتجاوز خيار السرقة هذا 10٪ ولا يجب أن يكون له تأثير كبير على أداء التطبيق داخل الجهاز الظاهري.
  
• تعتبر المعلمة LA بشكل غير صحيح. بتعبير أدق ، في كل لحظة بعينها ، يُعتبر هذا صحيحًا ، ولكن عندما يتم حسابه لمدة دقيقة واحدة ، يتضح أنه قد تم الاستهانة به. على سبيل المثال ، إذا كان جهاز ظاهري واحد يستهلك كل معالجاته لمدة نصف دقيقة بالضبط في ثلث المشرف ، فسيكون LA في الدقيقة 0.15 على برنامج hypervisor ؛ أربعة مثل هذه الأجهزة الافتراضية تعمل في وقت واحد سوف تعطي 0.6. وحقيقة أنه لمدة نصف دقيقة على كل منهما كان هناك سرقة برية بنسبة 25 ٪ في لوس أنجلوس ، لم يعد من الممكن سحبها.
  
• مرة أخرى ، بسبب القائد الذي قرر أن شخصا ما كان يأكل أكثر من اللازم ، والسماح لهذا الانتظار. في غضون ذلك ، أقوم بتبديل السياق ومعالجة المقاطعات وتنفيذ أشياء أخرى مهمة في النظام. نتيجة لذلك ، لا ترى بعض الأجهزة الظاهرية أي مشكلات ، بينما يواجه البعض الآخر تدهورًا خطيرًا في الأداء.
  

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

هناك مليون سبب آخر لتشويه العائد الصادق لوقت المعالج على الجهاز الظاهري. على سبيل المثال ، يضيف hypertreading و NUMA التعقيد إلى العمليات الحسابية. إنها تخلط بين اختيار kernel لتنفيذ العملية ، لأن sheduler يستخدم المعاملات - الأوزان ، والتي عند تبديل السياقات تجعل الحساب أكثر صعوبة.

- , , , . - . , , - (, 2 , ).

, . - . , , perf, sysdig, systemtap, .

5.

1. - steal - , . , 5-10 %. , . , .
   
2. steal , steal .
   
3. , . , . — .
   
4. steal ( , , ).
   
5. steal , , , , . , .