CPU Ready شيء قد لا تكون على دراية به. للوهلة الأولى ، قد يبدو الأمر جيدًا ولكن للأسف ليس كذلك. لقد عانت وحدة المعالجة المركزية جاهزة من البيئات الافتراضية لفترة أطول مما كنا نعرف ما كانت عليه. يعرّف برنامج VMware هذا بأنه 'النسبة المئوية للوقت الذي كان فيه الجهاز الظاهري جاهزًا ، ولكن لا يمكن جدولته للتشغيل على وحدة المعالجة المركزية الفعلية. يعتمد وقت استعداد وحدة المعالجة المركزية على عدد الأجهزة الافتراضية على المضيف وأحمال وحدة المعالجة المركزية الخاصة بهم '. بدأ Hyper-V مؤخرًا فقط في توفير هذا العداد (معالج Hyper-V Hypervisor الظاهري / وقت انتظار وحدة المعالجة المركزية لكل إرسال) وقد لا توفر برامج Hypervisor الأخرى هذا المقياس.
لفهم ماهية CPU Ready ، سنحتاج إلى فهم كيفية قيام برامج Hypervisor بجدولة وحدات المعالجة المركزية الافتراضية (vCPU) إلى وحدات المعالجة المركزية الفعلية (pCPU). عند الحاجة إلى وقت vCPU في جهاز افتراضي ، يجب جدولة vCPU (وحدات المعالجة المركزية الافتراضية) مقابل pCPU (s) بحيث يمكن تشغيل الأوامر / العمليات / سلاسل العمليات مقابل pCPU. في عالم مثالي ، لا توجد نزاعات أو اختناقات على الموارد عندما يحتاج ذلك إلى الحدوث. عندما يحتاج VCPU واحد VM إلى جدولة الوقت مقابل pCPU ، يتوفر نواة pCPU وتكون وحدة المعالجة المركزية جاهزة للغاية في هذا العالم المثالي. من المهم ملاحظة أن وحدة المعالجة المركزية جاهزة دائمًا ولكن في عالم مثالي فهي قليلة جدًا ولا يتم ملاحظتها.
في العالم الواقعي ، تتمثل إحدى مزايا المحاكاة الافتراضية في أنه يمكنك المراهنة على أن العديد من أجهزة VM الخاصة بك لن تؤدي إلى ارتفاع كل وحدات vCPU الخاصة بها في نفس الوقت ، وإذا كانت منخفضة جدًا في استخدام VMs ، فيمكنك حتى إجراء تخمينات حول مقدار ما يمكنك قم بتحميل مضيفك الفعلي بناءً على استخدام وحدة المعالجة المركزية واستخدام ذاكرة الوصول العشوائي. في الماضي ، تم تقديم توصيات للحصول على 4 وحدات معالجة مركزية إلى وحدة وحدة معالجة مركزية واحدة أو حتى نسبة 10: 1 اعتمادًا على عبء العمل. على سبيل المثال ، قد يكون لديك معالج رباعي النواة واحد ولكن لديك 4 وحدات افتراضية مع وحدات معالجة مركزية لكل وحدة لتمنحك 16 وحدة معالجة مركزية إلى 4 وحدات معالجة وحدة معالجة مركزية أو 4: 1. لكن ما بدأ المهندسون في رؤيته هو أن البيئات كانت بطيئة للغاية ولم يتمكنوا من معرفة السبب. يبدو استخدام ذاكرة الوصول العشوائي جيدًا ، وقد يكون استخدام وحدة المعالجة المركزية على الأجهزة المضيفة الفعلية منخفضًا جدًا ، أقل من 20٪. كان وقت استجابة التخزين منخفضًا للغاية ، لكن الأجهزة الافتراضية كانت بطيئة للغاية.
ما كان يحدث في هذا السيناريو كان وحدة المعالجة المركزية جاهزة. كانت هناك قائمة انتظار تتشكل من وحدة المعالجة المركزية الافتراضية جاهزة للجدولة ولكن لا توجد وحدة معالجة وحدة معالجة مركزية متاحة للجدولة مقابلها. سيقوم برنامج Hypervisor بإيقاف الجدولة والتسبب في زمن انتقال الضيف VM. إنه قاتل صامت حتى السنوات الأخيرة ، لم تكن هناك أدوات كثيرة للكشف عنها. في Windows VM ، سيستغرق التمهيد إلى الأبد ، وعندما يحدث أخيرًا ، عند النقر فوق قائمة ابدأ ، سيستغرق الأمر وقتًا طويلاً للظهور. يمكنك حتى النقر فوقه مرة أخرى معتقدًا أنه لم يقبل النقرة الأولى ، وعندما تدرك ذلك في النهاية ، ستحصل على نقرة مزدوجة. في نظام التشغيل Linux ، قد يتم تشغيل جهاز VM في وضع القراءة فقط أو حتى تبديل أنظمة الملفات إلى وضع القراءة فقط في وقت ما لاحقًا.
فكيف نكافح استعداد وحدة المعالجة المركزية؟ هناك عدة طرق يمكن أن تساعد. الأول هو مراقبة مقاييس استعداد وحدة المعالجة المركزية. في برنامج VMware ، لا يوصى بتجاوز 10٪ ولكن في التجربة الشخصية ، يبدأ المستخدمون في ملاحظة ما يزيد عن 5-7٪ اعتمادًا على نوع VM وما يتم تشغيله.
أدناه سأستخدم بعض الأمثلة من برنامج VMware ESXi 5.5 لإظهار استعداد وحدة المعالجة المركزية. باستخدام سطر الأوامر ، قم بتشغيل 'esxtop'. اضغط على 'c' لعرض وحدة المعالجة المركزية وسترى العمود ' ٪ RDY 'لوحدة المعالجة المركزية جاهزة. يمكنك الضغط على رأس المال ' الخامس 'للعرض VM فقط.
هنا يمكنك أن ترى أن٪ RDY مرتفع إلى حد ما بالنسبة لبيئة غير مستخدمة إلى حد ما. في هذه الحالة ، يقوم ESXi 5.5 الخاص بي بتشغيل VM اختبار أعلى VMware Fusion (Mac Hypervisor) ، لذلك من المتوقع أن يكون قليلاً في النهاية نظرًا لأننا نشغل VM على برنامج Hypervisor فوق برنامج Hypervisor آخر.
في عميل vSphere ، يمكنك سحب الجهاز الظاهري المحدد والنقر فوق علامة تبويب الأداء. من هناك انقر على 'خيارات الرسم البياني'
ضمن خيارات المخطط ، حدد CPU ، الوقت الفعلي (إذا كان لديك vCenter ، فقد يكون لديك خيارات توقيت أخرى غير الوقت الحقيقي). من هناك في العدادات ، حدد 'جاهز'. قد تحتاج إلى إلغاء تحديد عداد مختلف لأن العرض لا يسمح إلا بنوعين من البيانات في أي وقت.
ستلاحظ أن هذه القيمة هي تلخيص للجاهزية مقابل النسبة المئوية. فيما يلي رابط لمقالة قاعدة معارف VMware حول كيفية تحويل المقاييس الملخصة إلى نسبة مئوية. - https://kb.vmware.com/kb/2002181
عند شراء الأجهزة ، يساعد المزيد من النوى في تقليل تأثير استعداد وحدة المعالجة المركزية. يساعد أيضًا Hyperthreading. على الرغم من أن Hyperthreading لا يوفر نواة ثانية كاملة لكل نواة أساسية ، إلا أنه عادةً ما يكون كافياً للسماح بجدولة وحدة المعالجة المركزية الافتراضية (vCPU) إلى وحدة المعالجة المركزية (pCPU) والمساعدة في تخفيف المشكلة. على الرغم من أن برامج Hypervisor بدأت في الابتعاد عن توصية نسبة vCPU إلى pCPU ، إلا أنه يمكنك عادةً القيام بعمل جيد في بيئة مستخدمة بشكل معتدل مع 4: 1 والانتقال من هناك. عندما تبدأ في تحميل الأجهزة الافتراضية ، انظر إلى زمن استجابة وحدة المعالجة المركزية ووحدة المعالجة المركزية جاهزة والشعور العام والأداء. إذا كان لديك بعض أجهزة VM ذات الضربات الثقيلة ، فقد ترغب في فصلها في مجموعات أخرى واستخدام نسبة أقل وإبقائها خفيفة. من ناحية أخرى ، بالنسبة لأجهزة VM حيث الأداء ليس مفتاحًا ولا بأس في تشغيلها بطيئًا ، يمكنك الاشتراك أكثر من ذلك بكثير.
يعد تحجيم الأجهزة الافتراضية بشكل مناسب أيضًا أداة ضخمة لمكافحة استعداد وحدة المعالجة المركزية. يوصي العديد من البائعين بمواصفات تفوق ما قد يحتاجه VM بالفعل. تقليديا المزيد من وحدات المعالجة المركزية والمزيد من النوى = المزيد من الطاقة. تكمن المشكلة في البيئة الافتراضية في أن برنامج Hypervisor يجب أن يقوم بجدولة جميع وحدات vCPU إلى وحدات pCPU في نفس الوقت تقريبًا وقد يكون قفل وحدات pCPU مشكلة. إذا كان لديك 8 vCPU VM ، فيجب عليك قفل 8 وحدات pCPU للسماح لهم بالجدولة في نفس الوقت. إذا كان جهاز vCPU VM الخاص بك يستخدم فقط 10٪ من إجمالي vCPUs في أي وقت ، فمن الأفضل خفض عدد vCPU إلى 2 أو 4. ومن الأفضل تشغيل VM بنسبة 50-80٪ CPU مع أقل من 10٪ في المزيد من وحدات المعالجة المركزية الافتراضية. ترجع هذه المشكلة جزئيًا إلى أن برنامج جدولة وحدة المعالجة المركزية لنظام التشغيل مصمم لاستخدام أكبر عدد ممكن من النوى ، في حين أنه إذا تم تدريبه على الوصول إلى الحد الأقصى من النوى قبل استخدام المزيد ، فقد تكون هذه مشكلة أقل. قد يكون أداء جهاز VM كبير الحجم جيدًا ولكنه قد يكون 'جارًا مزعجًا' لأجهزة VM الأخرى ، لذا فهي عادةً عملية يتعين عليك فيها المرور عبر جميع الأجهزة الافتراضية في المجموعة إلى 'الحجم المناسب' لها من أجل رؤية بعض مكاسب الأداء.
في كثير من الأحيان واجهت CPU Ready ومن الصعب البدء في تحديد الحجم الصحيح لأجهزة VM أو الترقية إلى المعالجات ذات النوى الأكثر. إذا كنت في هذا الموقف ، فإن إضافة المزيد من المضيفين في مجموعتك يمكن أن يساعد في ذلك لنشر الحمل عبر المزيد من المضيفين. إذا كان لديك مضيفات بها نوى / معالجات أكثر من غيرها ، فإن ربط VCPU VMs العالية بهذه المضيفات الأساسية الأعلى يمكن أن يساعدك أيضًا. تريد التأكد من أن مضيفك الفعلي يحتوي على نفس عدد النوى على الأقل إن لم يكن أكثر من VM ، وإلا سيكون بطيئًا / صعبًا جدولة فائض وحدة المعالجة المركزية (vCPU) إلى pCPU نظرًا لأنه يلزم قفلها في نفس الوقت تقريبًا .
أخيرًا ، قد يدعم المشرف الخاص بك الحجوزات والقيود على الجهاز الظاهري. في بعض الأحيان يتم تعيين الأطروحات عن طريق الخطأ. يمكن أن تتسبب الإعدادات القوية على هذه الأجهزة في أن تكون وحدة المعالجة المركزية جاهزة عندما تكون الموارد الأساسية متاحة لها في الواقع. من الأفضل عادةً استخدام الحجوزات والقيود باعتدال وفقط عند الضرورة القصوى. بالنسبة للجزء الأكبر ، فإن الكتلة ذات الحجم المناسب ستوازن الموارد بشكل مناسب وهذه عادة ليست هناك حاجة.
باختصار ، أفضل دفاع ضد CPU Ready هو معرفة أنه موجود وكيفية التحقق منه. يمكنك بعد ذلك تحديد أفضل خطوات التخفيف لبيئتك بشكل منهجي في ضوء ما سبق. بالنسبة للجزء الأكبر ، تنطبق المعلومات الواردة في هذه المقالة بشكل عام على أي برنامج Hypervisor ، على الرغم من أن لقطات الشاشة والرسوم البيانية تنطبق بشكل خاص على برنامج VMware.
5 دقائق للقراءة
