تعرف على الاستخدام العالي لوحدة المعالجة المركزية (CPU) الذي تم الإعلام عنه بواسطة vManage لأنظمة التشغيل السحابية طراز VEdge 5000/2000/1000/100B و vEdge
المحتويات
المقدمة
يوضح هذا المستند سبب إمكانية مشاهدة إستخدام عال لوحدة المعالجة المركزية (CPU) تم الإعلام عنه في vManage لأنظمة السحابة vEdge 5000/2000/1000/100B و vEdge على الرغم من أن أداء الأنظمة يكون طبيعيا مع عدم وجود وحدة معالجة مركزية (CPU) عالية تم الإبلاغ عن عرضها في الجزء العلوي.
تعرف على الاستخدام العالي لوحدة المعالجة المركزية (CPU) الذي تم الإبلاغ عنه على الأنظمة الأساسية السحابية لملقمي vEdge 5000/2000/1000/100B و vEdge
مع الإصدارات 17.2.x والإصدارات الأحدث، يمكن ملاحظة زيادة في إستهلاك وحدة المعالجة المركزية (CPU) والذاكرة لمنصات شبكات vEdge و vEdge. يتم ملاحظة ذلك في لوحة معلومات vManage لجهاز معين. وفي بعض الحالات، يؤدي ذلك أيضا إلى زيادة عدد التنبيهات والتحذيرات في vManage.
الشرح
يرجع سبب إستخدام وحدة المعالجة المركزية (CPU) العالي الذي تم الإعلام عنه عندما يعمل الجهاز بشكل طبيعي مع عادي أو منخفض أو لا يوجد حمل إلى تغيير في الصيغة المستخدمة لحساب الاستخدام. مع الإصدارات 17.2، يتم حساب إستخدام وحدة المعالجة المركزية (CPU) استنادا إلى متوسط التحميل من حالة نظام العرض على vEdge.
يعرض vManage إستخدام وحدة المعالجة المركزية (CPU) في الوقت الفعلي للجهاز. إنه يسحب متوسط دقيقة واحدة [min1_avg] ومتوسط 5 دقائق [min5_avg] استنادا إلى البيانات التاريخية. يتضمن متوسط الحمولة، بحكم التعريف، أشياء مختلفة وليس فقط دورات وحدة المعالجة المركزية (CPU) التي تساهم في حساب الاستخدام. على سبيل المثال، يتم مراعاة وقت انتظار الإدخال/الإخراج، ووقت انتظار العملية، والقيم الأخرى عند تقديم هذه القيمة للنظام الأساسي. في هذه الحالة، تتجاهل القيم الموضحة لحالات وحدة المعالجة المركزية وقيم وحدة المعالجة المركزية في الأمر العلوي من vShell.
فيما يلي مثال على كيفية حساب إستخدام وحدة المعالجة المركزية (CPU)، وهو متوسط حمل يبلغ دقيقة واحدة، وإظهاره في لوحة معلومات vManage:
عند التحقق من التحميل من واجهة سطر الأوامر (CLI) الخاصة بالإصدار vEdge، يمكن ملاحظة ذلك:
vEdge# show system status | include Load Load average: 1 minute: 3.10, 5 minutes: 3.06, 15 minutes: 3.05 Load average: 1 minute: 3.12, 5 minutes: 3.07, 15 minutes: 3.06 Load average: 1 minute: 3.13, 5 minutes: 3.08, 15 minutes: 3.07
Load average: 1 minute: 3.10, 5 minutes: 3.07, 15 minutes: 3.05
وفي هذه الحالة، يتم حساب إستخدام وحدة المعالجة المركزية (CPU) استنادا إلى متوسط حمل / # من المراكز (vCPUs). على سبيل المثال، تحتوي العقدة على 4 مراكز. وبعد ذلك يتم تحويل متوسط الحمل بمعامل 100 قبل أن تقسم على عدد المراكز. عندما تقوم بتوسيط متوسط الحمل من كل النوى وتضرب ب 100، فإنك تصل إلى قيمة ~310. خذ هذه القيمة وقسمها على 4 محاصيل، أي قراءة وحدة المعالجة المركزية (CPU) من 77.5٪، والتي تتوافق مع القيمة المرئية في الرسم البياني في الوقت الفعلي في vManage التي تم التقاطها حوالي الوقت الذي تم فيه تجميع إخراج واجهة سطر الأوامر (CLI) وكما هو موضح في الصورة.
لعرض متوسطات الحمل وعدد مراكز وحدة المعالجة المركزية (CPU) في النظام، يمكن الرجوع إلى إخراج الأعلى من vShell على الجهاز.
في المثال التالي، يحتوي vEdge على 4 وحدات معالجة مركزية (vCPU). يتم إستخدام المركز الأول (CPU0) ل التحكم (يرى من خلال إستخدام المستخدم الأقل) بينما يتم إستخدام المراكز الثلاثة المتبقية ل البيانات:
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 694 root 20 0 1908m 204m 131m S 1 2.8 15:29.95 ftmd 496 root 20 0 759m 72m 3764 S 0 1.0 1:31.50 confd
للحصول على عدد وحدات المعالجة المركزية (CPU) من واجهة سطر الأوامر (CLI) الخاصة ب vEdge، يمكن إستخدام هذا الأمر:
vEdge# show system status | display xml | include total_cpu
<total_cpu_count>4</total_cpu_count>
يوجد مثال آخر لحساب القيمة الموضحة في vManage على vEdge 1000 هنا. بعد إصدار top من vShell، L مهتم لعرض الحمل لجميع المراكز:
top - 18:19:49 up 19 days, 1:37, 1 user, load average: 0.55, 0.71, 0.73
نظرا لأن الخادم طراز vEdge 1000 يحتوي على وحدة معالجة مركزية واحدة فقط متوفرة، فإن الحمل الذي تم الإبلاغ عنه هنا هو 55٪ (0.55*100).
إستخدام عال لوحدة المعالجة المركزية مع معالجة FP-UM
يمكنك أيضا في بعض الأحيان ملاحظة من الأعلى أن عملية fp-um تعمل بشكل عالي وتظهر ما يصل إلى 100٪ من وحدة المعالجة المركزية. وهذا متوقع على مراكز وحدة المعالجة المركزية (CPU) التي يتم إستخدامها لمعالجة مستوى البيانات.
من الأمر top المشار إليه سابقا، تعمل 3 مراكز على وحدة معالجة مركزية (CPU) بنسبة 100٪، بينما يظهر 1 مراكز الاستخدام العادي:
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 ...
يتم إستخدام هذا البرنامج الأساسي الأول (CPU0) للتحكم والنوى الثلاثة المتبقية المستخدمة للبيانات. كما ترى في قائمة العمليات، فإن عملية fp-um تستخدم تلك الموارد.
FP-UM هي عملية تستخدم برنامج تشغيل وضع إستفتاء، مما يعني أنها تجلس وتستعرض المنفذ الأساسي للحزم بشكل مستمر بحيث يمكنها معالجة أي إطار بمجرد إستلامه. تتعامل هذه العملية مع إعادة التوجيه وهي مكافئة لإعادة توجيه المسار السريع في VEdge 1000 و vEdge 2000 و vEdge 100. تستخدم Intel بنية وضع الاستطلاع هذه لمعالجة الحزم بفعالية استنادا إلى إطار عمل مجموعة أدوات تطوير مستوى البيانات (DPDK). نظرا لتنفيذ إعادة توجيه الحزمة في حلقة محكمة، فإن وحدة المعالجة المركزية تظل عند 100٪ أو ما يقرب منها في جميع الأوقات. وعلى الرغم من القيام بذلك، لم يتم إدخال زمن وصول من خلال وحدات المعالجة المركزية (CPU) هذه حيث إن هذا السلوك هو السلوك المتوقع.
يمكن العثور على معلومات أساسية حول إستطلاع DPDK هنا.
تستخدم الأنظمة الأساسية طراز vEdge Cloud و vEdge 5000 نفس بنية إعادة التوجيه، كما تعرض نفس السلوك في هذا الصدد. هنا مثال من VEdge 5000 سحبت من المخرج الأعلى. يحتوي على 28 مركزا، منها 2 (CPU0 و CPU1) يتم إستخدامها للتحكم (مثل vEdge 2000) و 26 يتم إستخدامها للبيانات.
top - 02:18:30 up 1 day, 7:33, 1 user, load average: 26.24, 26.28, 26.31 Tasks: 382 total, 27 running, 355 sleeping, 0 stopped, 0 zombie Cpu0 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 79.4%us, 20.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu8 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu9 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu10 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu11 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu12 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu13 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu14 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu15 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu16 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu17 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu18 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu19 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu20 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu21 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu22 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu23 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu24 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu25 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu26 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu27 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32659508k total, 10877980k used, 21781528k free, 214788k buffers Swap: 0k total, 0k used, 0k free, 1039104k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2028 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-3 2029 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-4 2030 root 20 0 12.1g 668m 124m R 100 2.1 1897:12 fp-um-5 2031 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-6 2032 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-7 2034 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-9 2035 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-10 2038 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-13 2040 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-15 2041 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-16 2043 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-18 2045 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-20 2052 root 20 0 12.1g 668m 124m R 100 2.1 1897:18 fp-um-27 2033 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-8 2036 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-11 2037 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-12 2039 root 20 0 12.1g 668m 124m R 100 2.1 1897:09 fp-um-14 2042 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-17 2044 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-19 2046 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-21 2047 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-22 2048 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-23 2049 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-24 2050 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-25 2051 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-26 1419 root 20 0 116m 5732 2280 S 0 0.0 0:02.00 chmgrd 1323 root 20 0 753m 70m 3764 S 0 0.2 1:51.20 confd 1432 root 20 0 1683m 172m 134m S 0 0.5 0:58.91 fpmd
وهنا، يكون معدل التحميل مرتفعا دائما لأن 26 من المعالجات ال 28 تعمل بنسبة 100٪ بسبب العملية fp-um.
القرار
لا يعد إستخدام وحدة المعالجة المركزية (CPU) الذي تم الإبلاغ عنه في الإصدار vManage لإصدارات 17.2.x قبل الإصدار 17.2.7 هو الاستخدام الفعلي لوحدة المعالجة المركزية (CPU) ولكنه يتم حسابه بدلا من ذلك استنادا إلى متوسط الحمل. قد يؤدي ذلك إلى حدوث إرتباك في فهم القيمة التي تم الإبلاغ عنها ويؤدي إلى ظهور إنذارات خاطئة تتعلق بوحدة المعالجة المركزية (CPU) عالية بينما تعمل المنصة بشكل طبيعي مع حمل حركة المرور/الشبكة العادي أو المنخفض أو بدون حمل فعلي لحركة المرور/الشبكة.
ويتم تغيير/تعديل هذا السلوك باستخدام الإصدارات 17.2.7 و 18.2 التي يمكن من خلالها أن تكون قراءة وحدة المعالجة المركزية (CPU) دقيقة الآن استنادا إلى قراءة وحدة المعالجة المركزية_المستخدم من الأعلى.
وقد ذكرت هذه المسألة أيضا في ملاحظات الإصدار 17.2.
التعليقات