تجميع البيانات عندما يستهلك NSO وحدة معالجة مركزية (CPU) عالية

المقدمة

يصف هذا المستند مجموعة بيانات Network Services Orchestrator (NSO) اللازمة عند زيادة إستهلاك وحدة المعالجة المركزية إلى 100-150٪.

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

معلومات أساسية

وعندما تتم معالجة حركات متعددة من NB، يزداد إستهلاك وحدة المعالجة المركزية لوحدة المعالجة المركزية NSO إلى ما يقرب من 100-150٪ من الاستهلاك العادي. وعندما يحدث ذلك، فإنك بحاجة إلى العثور على السبب الذي يؤدي إلى خفض مستوى أداء وحدة المعالجة المركزية (CPU). وفي الوقت نفسه، لا يستجيب NSO لاستعلامات RESTCONF (في حالة إستخدامها) بشكل صحيح.

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

البيانات المطلوب تجميعها

من منظور لينوكس:

• لسبو
• قمة
• مجانا -h
• vmstat
• cat /proc/meminfo
• PSTREE -c
• بووكسو | فرز

ملاحظة: يمكنك التقاط هذه التفاصيل (باستثناء "lscpu") على فترات منتظمة لفهم كيفية تصرف النظام عندما تأتي الطلبات من NB.

من منظور NSO:

• ncs — الحالة | إحكام GREP
• تمكين تتبع التقدم:

  admin@ncs(config)# الالتزام بالتشغيل الجاف 

  cli{

      العقدة المحلية {

          تقدم البيانات {

               + تتبع كل {

               + الوجهة {

               + تقدم الملف-all.txt؛

               + سجل التنسيق؛

               +}

               +}

                }

      }

  }

  admin@ncs(config)# الالتزام

• التقاط المعلومات التالية كل 'n' ثانية (يمكن تشغيلها كنص):

مقسم = 0
بينما NCS —الحالة >& /dev/null؛ قم
ncs —debug-dump ncs.dd.$((seq++))؛
ncs —الحالة > ncs.stat.$((seq++)؛
وضع السكون 30، #مهيأ according  إلى المستخدم
تم

وفيما يلي بعض الخطوات العلاجية التي يمكن إتخاذها أيضا للتخفيف من حدة هذه المسألة:

1. حدد عدد جلسات العمل كما يلي ( حاليا، ليس لديك هذه المجموعة):

<session-limit>

  <session-limit>

    <context>rest</context>

    <max-sessions>100</max-sessions>

  </session-limit>

<//session-limit>

ب. تمكين قاعدة التدقيق للتأكد مما إذا كان قد تم قتل عملية NSO بواسطة شيء ما وإذا كان الأمر كذلك، قم بتسجيلها في audit.log:

Sudo AuditCTL -a مخرج، دائما -F arch=b64 -S قتل -k audit_kill

لاستكشاف الأخطاء وإصلاحها وتحليلها، تحتاج إلى التفاصيل السابقة بالإضافة إلى سجلات Audit.log و devel.log (يفضل أن تكون معينة على المستوى=trace) و ncs-java-vm.log و NB.

معلومات إضافية

س. كيف تتعامل NSO بالفعل مع طلبات RECconf من تطبيق NB؟

a. عندما يرسل تطبيق Northbound طلب RESTCONF، يتم التعامل معه كمعاملة فريدة تستند إلى NSO. وهذا يعني أنه يمكن ل NSO تأمين CDB بالكامل، وعدم السماح بأي معاملات أخرى حتى تكتمل الحركة الحالية.إذا تم ذلك، يتم الحفاظ على طبيعة المعاملات الخاصة ب NSO ويضمن إجراء التراجع في حالة أي مشاكل.

يمكن ل NSO Commit-Queue معالجة كل طلب معاملة لاحق عند اكتماله، ويمكنك تعقب تأمين الحركة في devel.log عند بدء/اكتمال الطلب. في حالات الاستخدام التي يتم فيها إجراء قدر كبير من الاستعلامات، يؤدي ذلك إلى إدخال مقدار كبير من المصاريف العامة في NSO، وتكون المعاملات في قائمة انتظار الالتزام لفترة أطول من المتوقع. وفي حالة تجميع طلبات RESTCONF، فسيزداد معدل الإنتاج، مع تقليل النفقات العامة للمعاملات. وسوف يكون مكتب خدمات المشتريات الوطني قادرا أيضا على القيام بكل ما بوسعه في الوقت نفسه، داخل أي صفقة منفردة. على سبيل المثال، إذا احتوت معاملة على تغييرين في تكوين الجهاز، فيمكن ل NSO تأمين CDB، والوصول إلى كلا الجهازين وتحريرهما في نفس الوقت، ثم إكمال الحركة وهذا على النقيض من عمليتين يحتوي كل منهما على جهاز واحد ويتم تغيير كليهما؛ حيث يمكن NSO تأمين CDB للحركة الأولى، وتحرير الجهاز الأول، وإكمال الحركة، ثم القيام بنفس الخطوات للجهاز الثاني.

معلومات ذات صلة