غالبًا ما يستفسر العملاء عن وقت سرقة المعالج (CPU steal time). خاصة أولئك الذين يستخدمون المعالجات بشكل مكثف ويمثل ذلك بالنسبة لهم معيارًا رئيسيًا للأداء. هناك الكثير من الاختلافات في إعداد وسلوك المعالجات والنوى بين البيئات المادية والافتراضية. وحتى بين مزودي الخدمات السحابية، هناك اختلافات في الإعدادات تجعل المقارنة المباشرة أمرًا صعبًا في ظاهر الأمر. لهذا السبب، رأينا أنه من المفيد تقديم نظرة عامة موجزة عن إعداداتنا ومنطق تخصيص المعالج للعملاء، بالإضافة إلى شرح المصادر الأكثر شيوعًا لوقت سرقة المعالج.
لذا أولاً، بالنسبة لأولئك الذين ليسوا على دراية بهذا المفهوم، فإن وقت سرقة المعالج (CPU steal time) هو الوقت الذي يتعين فيه على معالجك الافتراضي داخل خادمك السحابي انتظار المعالج المادي الحقيقي بينما يكون برنامج مراقبة الأجهزة الافتراضية (hypervisor) مشغولاً باستخدامه لأشياء أخرى (مثل الأجهزة الافتراضية/الخوادم السحابية الأخرى). هذا مقال رائع عن وقت سرقة المعالج يستحق القراءة حقًا.
معلومات بسيطة حول إعداد المعالج لدينا
أول شيء يجب فهمه يتعلق بالطريقة التي نخصص بها النوى بين الأجهزة الافتراضية على كل عقدة حوسبة مادية تستضيف حوسبتك. إن المعالجات ونواها في CloudSigma مشتركة. بعبارة أخرى، نحن لا نربط الخادم السحابي للعميل بنوى معينة. يتم تعيين وقت المعالج بواسطة جدولة عقدة الحوسبة المادية ديناميكيًا وكل شيء مشترك. ونحن نعتقد أن هذا له عدد من الفوائد في تقديم أداء أكثر موثوقية بشكل كلي من خلال السماح لعقدة الحوسبة بإجراء تعديلات تخصيص معقولة على الفور لموازنة الحمل.
بالتزامن مع هذا، نحن نستخدم Control Groups (المعروفة اختصارًا باسم cgroups) لضمان وقت كافٍ للمعالج لكل خادم من الخوادم السحابية بما يتماشى مع الموارد التي قمت بتعيينها عبر حجم الخادم. في النهاية، يقرر المجدول ما يجب فعله بأي موارد متبقية ومجموعات cgroups. ومن الجدير بالذكر أيضًا أننا نحتفظ بمجموعة من النوى المحددة لتكون خارج نطاق التخصيص لأعباء عمل حوسبة العملاء. نحن نستخدم هذه النوى لتشغيل نظام تشغيل المضيف المادي. وبشكل خاص، نحتفظ بنوى إضافية لمعالجة عمليات الشبكات والتخزين. يهدف كل هذا إلى زيادة استقرار الجهاز بشكل عام. علاوة على ذلك، فإنه يساعد في تقديم مستويات أداء موثوقة بمرور الوقت بشكل مستقل عن حمل العملاء الآخرين بالنسبة لك كعميل.
مصادر وقت سرقة المعالج في البيئة الافتراضية
على عكس البيئة المادية، هناك مصادر وحالات متعددة يمكنك أن تواجه فيها وقت سرقة المعالج. هذا لأن الأمور أكثر تعقيدًا في البيئة الافتراضية متعددة المستأجرين. وليست جميعها حالات لا تحصل فيها بالفعل على وقت المعالج الذي ينبغي لك الحصول عليه، بل في الواقع، في كثير من الحالات، يمكنك غالبًا استيعاب دورات المعالج الاحتياطية التي تتجاوز الحجم المخصص لك، ولكن هذه ليست حالة ترى فيها وقت سرقة المعالج. وفيما يلي الحالات الثلاث الأكثر شيوعًا بمزيد من التفصيل.
خادمك السحابي محمل بشكل زائد
هذا يحدث! يريد الجميع استخدام سعة قريبة قدر الإمكان من السعة الكاملة لما يدفعون مقابله، ومع ذلك، إذا كان المعالج المخصص لخادمك السحابي الافتراضي غير كافٍ لمعالجة عبء العمل، فقد ترى وقت سرقة المعالج مع تراكم الأمور واصطفافها في طابور داخل المعالج الافتراضي. إذا كان هذا هو السبب الجذري لوقت سرقة المعالج، فإن الحل هو تغيير حجم الخادم السحابي. وإذا كان هذا تحميلاً زائدًا مؤقتًا، فيمكنك ترك الأمور دون تغيير بأمان. سترى وقت سرقة المعالج يختفي عندما ينخفض الحمل لديك.
الخادم المادي الذي يستضيف خادمك السحابي محمل بشكل زائد
إذا كان هناك تحميل زائد على المضيف، فإن هذا في هذه الحالة يعد فشلاً من جانبنا. إنه أمر نادر ولكنه قد يحدث. في هذه الحالة، نستخدم الهجرة الحية لنقل الأجهزة الافتراضية دون انقطاع إلى عقد حوسبة مادية أخرى لخفض مستويات الحمل إلى المستويات الطبيعية. بشكل عام، نحافظ على المضيفين بمستوى أقل بكثير من الحمل الكامل. لذا، إذا استمررت في ملاحظة ذلك لفترة طويلة، يرجى الاتصال بنا. يمكن لدعمنا المجاني على مدار الساعة طوال أيام الأسبوع التحقق من المضيف المادي الذي تتواجد عليه. وإذا لم يكن هناك تحميل زائد، فمن غير المرجح أن يكون هذا هو السبب الجذري لوقت سرقة المعالج لديك.
أنت تستخدم حجماً أصغر للنواة الافتراضية
في CloudSigma نمنحك القدرة على تحديد حجم النواة الافتراضية للاستفادة من وجود المزيد من خيوط الـ CPU لنوى افتراضية أصغر لأي حجم خادم سحابي. سيرى الخادم السحابي داخل نظام التشغيل دائماً حجم النواة كحجم مادي كامل.
إذا كانت النواة المادية هي 2.6GHz ولكن الـ VM الخاص بك هو 4GHz ونواتين، فستكون كل نواة افتراضية هي 2GHz. لذلك سترى دائماً وقت السرقة (steal time). في الواقع، هذا لأنك تتلقى مقداراً متناسباً من النواة الإجمالية وليس الحجم الكامل بسبب صغر حجم النواة الافتراضية. على هذا النحو، يجب عليك دائماً تعديل أي حسابات لوقت سرقة الـ CPU لأخذ حجم النواة الافتراضية الأصغر في الاعتبار إذا كنت تستخدم ذلك بالفعل. لتجنب ذلك، يمكنك استخدام حجم النواة الكامل لكل نواة. يمكنك القيام بذلك عن طريق توسيع حجم النواة الافتراضية إلى حجم نواة الـ CPU الكامل (على سبيل المثال Intel v4 2.6GHz).
الخلاصة
إن وقت سرقة الـ CPU في السحابة أكثر تعقيداً قليلاً من البيئات المادية التقليدية أحادية المستأجر. ومع ذلك، فإنه لا يزال موجوداً بالتأكيد. إلا أن تقارير وقت سرقة الـ CPU بواسطة أنظمة التشغيل لم تتكيف مع الظروف المختلفة. هذا يعني أنه يمكنك الحصول على نتائج إيجابية خاطئة. عندما تجد وقت سرقة الـ CPU، فإن هذا يعني عادةً وجود قيود على الموارد. نأمل أن يساعدك هذا المنشور في تحديد السبب الجذري بسرعة وضمان استمرار العمليات بسلاسة.
حوسبة سعيدة!
روبرت
التعليقات
لا توجد تعليقات بعد. كن أول من يعلق.