استكشاف أخطاء وحدة المعالجة المركزية المرتفعة وإصلاحها على موجّه ASR1000 Series

المقدمة

يصف هذا المستند كيفية استكشاف مشكلات وحدة المعالجة المركزية المرتفعة وإصلاحها على موجّه ASR1000 series.

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

المتطلبات

تُوصي Cisco بفهم بنية ASR1000 لتفسير هذا المستند واستخدامه. 

الوصف

قد يتم تعريف وحدة المعالجة المركزية (CPU) المرتفعة على موجّه Cisco على أنها الحالة التي يكون فيها استخدام وحدة المعالجة المركزية (CPU) على الموجّه أعلى من الاستخدام العادي. في بعض السيناريوهات ، يُتوقع زيادة استخدام وحدة المعالجة المركزية بينما في السيناريوهات الأخرى قد تشير إلى وجود مشكلة. يمكن تجاهل الاستخدام المؤقت لوحدة المعالجة المركزية المرتفعة على الموجّه بسبب تغيير الشبكة أو تغيير التكوين وهو سلوك متوقع.

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

أسباب ارتفاع وحدة المعالجة المركزية هي:

1. تستقبل وحدة المعالجة المركزية (CPU) لمستوى التحكم الكثير من حركة المرور المسيرة
2. معالج يعمل بشكل غير متوقع وينتج عنه استخدام مفرط لوحدة المعالجة المركزية
3. يتم استخدام معالج مستوى البيانات بشكل مفرط /تم تجاوز حد الاشتراك
4. عدد كبير من مقاطعات المعالج

لا تُعد CPU المرتفعة دائمًا مشكلة في موجّه ASR1000 series حيث أن استخدام وحدة المعالجة المركزية للموجّه يتناسب طرديًا مع الحمل على الموجّه.   على سبيل المثال، إذا كان هناك تغيير في الشبكة، فسوف يتسبب ذلك في قدر كبير من حركة مرور مستوى التحكم حيث ستتم إعادة دمج الشبكة. لذلك، نحتاج إلى تحديد السبب الجذري للاستخدام المفرط لوحدة المعالجة المركزية لتحديد ما إذا كان هذا السلوك متوقعًا أم يمثل مشكلة.

يوجد أدناه مخطط  يوضح تفاصيل عملية خطوة بخطوة حول كيفية استكشاف مشكلات وحدة المعالجة المركزية (CPU) المرتفعة وإصلاحها:

خطوات استكشاف الأخطاء وإصلاحها

الخطوة 1 – تحديد الوحدة ذات وحدة المعالجة المركزية المرتفعة

يحتوي ASR1000 على العديد من وحدة المعالجة المركزية المختلفة عبر الوحدات المختلفة. لذلك، نحتاج إلى رؤية أي وحدة تظهر استخدامًا أكبر من الاستخدام العادي. ويمكن ملاحظة ذلك من خلال القيمة الخاملة، حيث أنه كلما قلت القيمة الخاملة، زاد استخدام وحدة المعالجة المركزية لتلك الوحدة. تعكس وحدة المعالجة المركزية المختلفة هذه مستوى التحكم في الوحدات.

حدد الوحدة داخل الجهاز التي تتم ملاحظتها لتجربة CPU مرتفعة. هل هو RP، أو ESP، أو SIP باستخدام الأمر أدناه

   show platform software status control-processor brief

ارجع إلى الإخراج أدناه لعرض العمود المميز

إذا كان RP يحتوي على قيمة خاملة منخفضة، فانتقل إلى الخطوة 2 النقطة 1

إذا كانت ESP تحتوي على قيمة خاملة منخفضة، فتابع إلى الخطوة 3 النقطة 2 

إذا كان SIP يحتوي على قيمة خاملة منخفضة، فانتقل إلى الخطوة 4 النقطة 3

   Router#show platform software status control-processor brief

   متوسط الحمل
   الفتحة    الحالة   1-Min   5-Min  15-Min
   RP0     سليم 0.00    0.02    0.00
   ESP0   سليم 0.01    0.02    0.00
   SIP0   سليم   0.00    0.01    0.00

   الذاكرة (كيلوبايت)
   الفتحة   الحالة    إجمالي       المُستخدم (Pct)     مجاني (Pct)  مُلتزم به (Pct)
   RP0    سليم   2009376  1879196 (94%)   130180 ( 6%)    1432748 (71%)
   ESP0   سليم   2009400   692100 (34%)  1317300 (66%)     472536 (24%)
   SIP0   سليم    471804   284424 (60%)   187380 (40%)     193148 (41%)

   استخدام CPU
   الفتحة   CPU   نظام المستخدم  جيد   خامل    IRQ  SIRQ IOwait
   RP0     0   2.59    2.49  0.00  94.80  0.00   0.09   0.00
   ESP0    0   2.30   17.90  0.00  79.80  0.00   0.00   0.00
   SIP0    0   1.29    4.19  0.00  94.41  0.09   0.00   0.00

إذا كانت القيم الخاملة جميعها مرتفعة نسبيًا، فقد لا تكون هناك مشكلة في مستوى التحكم. لاستكشاف أخطاء مستوى البيانات وإصلاحها، يلزم مراقبة QFP الخاص بـ ESP. لا يزال من الممكن ملاحظة أعراض "ارتفاع وحدة المعالجة المركزية" بسبب استخدام QFP المفرط، والذي لن ينتج عنه ارتفاع في وحدة المعالجة المركزية (CPU) على معالجات مستوى التحكم. انتقل إلى الخطوة 6.

الخطوة 2 –  تحليل الوحدة

• معالج المسار

قم بالتأكيد داخل RP للمعالج الذي تمت ملاحظته لاستخدام وحدة المعالجة المركزية المرتفعة باستخدام الأمر أدناه. هل هي عملية Linux أم IOS؟

   show platform software process slot RP active monitor

إذا كانت النسبة المئوية لوحدة المعالجة المركزية (CPU) الخاصة بنظام IOS مرتفعة (linux_iosd-image)، فهل هي RP IOS. انتقل إلى الخطوة 3

إذا كانت النسبة المئوية لوحدة المعالجة المركزية (CPU) للعمليات الأخرى مرتفعة، فمن المحتمل أن يكون معالج Linux. انتقل إلى الخطوة 4

• معالج الخدمات المضمنة

قم بتأكيد ما إذا تمت ملاحظة معالج مستوى التحكم لاستخدام وحدة المعالجة المركزية المرتفعة داخل ESP. هل هو FECP؟

   show platform software process slot FP active monitor

إذا كانت العمليات مرتفعة، فهذا هو FECP، ثم انتقل إلى الخطوة 5

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

• معالج واجهة SPA

إذا تمت ملاحظة أن بروتوكول SIP يحتوي على استخدام وحدة المعالجة المركزية المرتفعة، فستتم ملاحظة أن بروتوكول IOCP يحتوي على وحدة معالجة مركزية مرتفعة. حدد العملية أو العمليات داخل IOCP التي تمت ملاحظتها للحصول على استخدام وحدة المعالجة المركزية (CPU) المرتفعة.

قم بإجراء التقاط حزمة وتحديد حركة المرور الأعلى من المعتاد وأي عمليات مقترنة بهذا النوع من حركة المرور. انتقل إلى الخطوة 7

الخطوة 3 – عمليات IOS

ارجع إلى الإخراج أدناه، حيث تمثل النسبة المئوية الأولى إجمالي استخدام وحدة المعالجة المركزية (CPU)، والنسبة المئوية الثانية هي استخدام وحدة المعالجة المركزية (CPU) للمقاطعة، وهي مقدار وحدة المعالجة المركزية المستخدمة لمعالجة الحِزم المسيّرة.

إذا كانت النسبة المئوية للمقاطعة مرتفعة، فإنها تشير إلى أن قدرًا كبيرًا من حركة المرور يتم توجيهه إلى RP، (يمكن تأكيد ذلك باستخدام الأمر show platform software infrastructure punt)

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

قم بتأكيد العملية أو العمليات التي تمت ملاحظتها للحصول على استخدام وحدة المعالجة المركزية المرتفعة داخل IOS وذلك باستخدام الأمر أدناه داخل IOS.

   show processes cpu sorted

حدد النسبة المئوية المرتفعة (إجمالي وحدة المعالجة المركزية أو وحدة المعالجة المركزية للمقاطعة)، ثم حدد العملية/العمليات الفردية إذا لزم الأمر. انتقل إلى الخطوة 7

   Router#show processes cpu sorted

   إستخدام وحدة المعالجة المركزية (CPU) لمدة خمس ثوان: 0% / 0%; دقيقة واحدة: 1%; خمس دقائق: 1%

   PID  وقت التشغيل(مللي ثانية)    تم الاستدعاء     uSecs     5Sec    1Min    5Min  TTY   العملية

   PID  وقت التشغيل(مللي ثانية)    تم الاستدعاء     uSecs     5Sec    1Min    5Min  TTY   العملية

   188        8143      434758        18    0.15%   0.18%   0.19%   0    Ethernet Msec Ti

   515         380        7050        53    0.07%   0.00%   0.00%   0    عملية SBC الرئيسية

     3        2154         215     10018    0.07%   0.00%   0.19%   0    Exec            

   380        1783       55002        32    0.07%   0.06%   0.06%   0    MMA DB TIMER    

    63        3132       11143       281    0.07%   0.07%   0.07%   0    IOSD ipc task   

     5           1           2       500    0.00%   0.00%   0.00%   0    IPC ISSU Dispatc

     6          19          12      1583    0.00%   0.00%   0.00%   0    RF Slave Main Th

     8           0           1         0    0.00%   0.00%   0.00%   0    مؤقتات الإبلاغ للقراءة فقط

     7           0           1         0    0.00%   0.00%   0.00%   0    EDDRI_MAIN      

    10           6          75        80    0.00%   0.00%   0.00%   0    مدير حمام السباحة    

     9        5671         538     10540    0.00%   0.14%   0.12%   0    التحقق من الأكوام     

الخطوة 4 – عمليات Linux

إذا لوحظ أن IOS قد أفرط في استخدام وحدة المعالجة المركزية، فسنحتاج إلى ملاحظة استخدام وحدة المعالجة المركزية لعملية linux الفردية. هذه العمليات هي العمليات الأخرى المُدرجة من show platform software process slot RP active monitor. حدد العملية أو العمليات التي تتم ملاحظتها لتجربة وحدة المعالجة المركزية المرتفعة ثم انتقل إلى الخطوة 7.

الخطوة 5 - عمليات FECP

إذا كانت هناك عملية أو عمليات مرتفعة، فمن المحتمل أن تكون تلك هي العمليات داخل FECP المسؤولة عن استخدام وحدة المعالجة المركزية المرتفعة، فانتقل إلى الخطوة 7

الخطوة 6 – استخدام QFP

إن معالج التدفق الكمي هو ASIC لإعادة التوجيه. لتحديد الحمل على محرك إعادة التوجيه، يمكن مراقبة QFP. يسرد الأمر أدناه حِزم الإدخال والإخراج (الأولوية وبدون أولوية) في الحِزم في الثانية، والبت في الثانية. يعرض السطر الأخير المقدار الإجمالي لحمل وحدة المعالجة المركزية بسبب إعادة توجيه الحزمة بالنسبة المئوية.

   show platform hardware qfp active datapath utilization

حدد ما إذا كان الإدخال أو الإخراج مرتفعًا، واعرض حمل العملية ثم انتقل إلى الخطوة 7

   Router#show platform hardware qfp active datapath utilization

     بروتوكول CPP 0: الانحراف الفرعي 0 5 ثوان 1 دقيقة 5 دقيقة 60 دقيقة

    الإدخال:  الأولوية (pps) 0 0

                     (حِزم في الثانية)         208      176      176      176

        بدون أولوية (حِزم في الثانية)           0        2        2        2

                     (حِزم في الثانية)          64      784      784      784

               الإجمالي (حِزم في الثانية)           0        2        2        2

                     (حِزم في الثانية)         272      960      960      960

    الناتج: الأولوية (pps) 0 0

                     (حِزم في الثانية)         192      160      160      160

        بدون أولوية (حِزم في الثانية)           0        1        1        1

                     (حِزم في الثانية)           0     6488     6496     6488

              الإجمالي (حِزم في الثانية)           0        1        1        1

                     (حِزم في الثانية)         192     6648     6656     6648

    المعالجة: الحمولة (pct) 0 0 0

الخطوة 7 – تحديد السبب الجذري وتحديد الإصلاح

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

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

مثال على استكشاف الأخطاء وإصلاحها

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

   Router#show platform software status control-processor brief
   متوسط الحمل
   الفتحة    الحالة   1-Min   5-Min  15-Min
   RP0    سليم   0.66   0.15   0.05
   ESP0   سليم   0.00   0.00   0.00
   SIP0   سليم   0.00   0.00   0.00

   الذاكرة (كيلوبايت)
   الفتحة   الحالة    إجمالي       المُستخدم (Pct)     مجاني (Pct)  مُلتزم به (Pct)
   RP0    سليم  2009376  1879196 (94%)   130180 ( 6%)   1432756 (71%)
   ESP0   سليم  2009400   692472 (34%) 1316928 (66%)    472668 (24%)
   SIP0   سليم   471804   284556 (60%)  187248 (40%)    193148 (41%)

   استخدام CPU
   الفتحة   CPU   نظام المستخدم  جيد   خامل    IRQ  SIRQ IOwait
   RP0     0   57.11  14.42  0.00   0.00  28.25  0.19   0.00
   ESP0    0    2.10  17.91  0.00  79.97   0.00  0.00   0.00
   SIP0    0    1.20   6.00  0.00  92.80   0.00  0.00   0.00

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

   Router#show processes cpu sorted
   إستخدام وحدة المعالجة المركزية (CPU) لمدة خمس ثوان: 36% / 84%; دقيقة واحدة: 34%; خمس دقائق: 9%
   PID  وقت التشغيل(مللي ثانية)  تم الاستدعاء     uSecs    5Sec    1Min   5Min  عملية TTY
   107       303230     50749     5975  46.69%  18.12%  4.45%   0  IOSXE-RP Punt Se
    63       105617    540091      195   0.23%   0.10%  0.08%   0  IOSD ipc task
   159        74792   2645991       28   0.15%   0.06%  0.06%   0  مؤشر ترابط VRRS الرئيسي
   116        53685    169683      316   0.15%   0.05%  0.01%   0  الوظائف لكل ثانية
     9       305547     26511    11525   0.15%   0.28%  0.16%   0  التحقق من الأكوام
   188       362507  20979154       17   0.15%   0.15%  0.19%   0  Ethernet Msec Ti
     3          147       186      790   0.07%   0.08%  0.02%   0  Exec
     2        32126     33935      946   0.07%   0.03%  0.00%   0  مقياس الحمل
   446          416     33932       12   0.07%   0.00%  0.00%   0  عملية VDC
   164        59945   5261819       11   0.07%   0.04%  0.02%   0  عمر إعادة محاولة IP ARP
    43         1703     16969      100   0.07%   0.00%  0.00%   0  رسائل استمرار نشاط IPC M  

من هذا الإخراج، يمكن ملاحظة أن إجمالي النسبة المئوية لوحدة المعالجة المركزية ونسبة المقاطعة أعلى من المتوقع. أهم عملية تستخدم وحدة المعالجة المركزية هي "IOSXE-RP Punt Se" وهي العملية التي تتعامل مع حركة المرور الخاصة بوحدة المعالجة المركزية لـ RP، وبالتالي يمكننا النظر بشكل أكبر في حركة المرور هذه المسيّرة إلى RP.

   Router#show platform software infrastructure punt
   إحصائيات واجهة LSMPI الداخلية:
   ممكّن=0، معطل=0، مكبوح=0، غير مكبوح=0، الحالة جاهزة
   المخازن المؤقتة للإدخال =  90100722
   المخازن المؤقتة للإخراج =  100439
   تعداد rxdone = ‫ 90100722
   تعداد txdone = ‫ 100436
   تعداد Rx بدون نوع جسيمات  =  0
   تعداد Tx بدون نوع جسيمات  =  0
   تعداد Txbuf من الظل  =  0
   لا توجد بداية للحزمة  =  0
   لا توجد نهاية للحزمة  =  0
   إحصائيات إسقاط التسيير:
   إصدار رديء  0
   نوع رديء  0
   كان لديه رأس ميزة  0
   كان لديه رأس منصة  0
   رأس الميزة مفقود  0
   عدم تطابق العنوان الشائع  0
   الطول الإجمالي السيئ  0
   طول الحزمة الرديء  0
   إزاحة شبكة تالفة  0
   ليس رأس تسيير  0
   نوع ارتباط غير معروف  0
   لا يوجد برنامج Swidb  1
   رأس ميزة ESS الرديئة 0
   لا توجد ميزة ESS  0
   لا توجد ميزة SSLVPN  0
   نوع التسيير بالنسبة لنا غير معروف  0
   سبب التسيير خارج النطاق  0
   تتسبب حزمة تسيير IOSXE-RP في:
       62210226  التحكم في الطبقة 2 والحِزم القديمة
            147  حِزم طلب أو استجابة ARP
       27801234  حِزم البيانات بالنسبة لنا
          84426  حِزم رسائل تنشيط اتصال RP<->QFP
              6  جمع الحِزم المتجاورة
           1647 حِزم التحكم بالنسبة لنا

       إحصائيات بروتوكول FOR_US Control IPv4:
              1647 حِزم OSPF
   الرسم البياني للحزمة (500 بايت/سلة)، متوسط الحجم في 92، من أصل 56:
    حجم الحزمة    تعداد داخلي    تعداد خارجي
         0+:    90097805 98790
       500+:           0 7

من خلال هذا الإخراج، يمكننا أن نرى أن هناك كمية كبيرة من الحِزم في "حِزم البيانات بالنسبة لنا" والتي تشير إلى حركة المرور الموجهة نحو الموجّه، وتم تأكيد أن هذا العداد تمت زيادته من خلال ملاحظة الأمر عدة مرات على مدار عدة دقائق. وهذا يؤكد أن وحدة المعالجة المركزية (CPU) يتم استخدامها بشكل مفرط من خلال كمية كبيرة من حركة المرور المسيّرة، والتي غالبًا ما تتحكم في حركة مرور مستوى التحكم. يمكن أن تتضمن حركة مرور مستوى التحكم ARP وSSH وSNMP وتحديثات المسار (BGP وEIGRP وOSPF) وما إلى ذلك. ومن خلال هذه المعلومات، يمكننا تحديد السبب المحتمل لارتفاع وحدة المعالجة المركزية (CPU) وهذا يساعد على استكشاف السبب الرئيسي وإصلاحه. على سبيل المثال، يمكن تنفيذ التقاط الحزمة أو مراقبة حركة المرور المختلفة لرؤية حركة المرور الدقيقة المسيّرة إلى RP والتي تسمح بتحديد السبب الجذري وحله لمنع حدوث مشكلة مماثلة في المستقبل.

بمجرد اكتمال التقاط الحزمة، فإن بعض الأمثلة لحركة المرور المسيّرة المحتملة هي:

• ARP: وقد يكون هذا بسبب عدد مفرط من طلبات ARP، والذي قد يحدث إذا كانت عناوين IP المتعددة ستقوم بإرسال طلبات ARP من خلال تكوين مسار IP إلى واجهة بث. قد يكون هذا أيضًا بسبب الإدخالات التي تم مسحها من جدول ARP وسيتعين إعادة معرفتها بناءً على إدخالات عنوان MAC التي انتهت صلاحيتها ، أو واجهات التشغيل/إيقاف التشغيل.

• بروتوكول النقل الآمن (SSH): قد يتسبب هذا في إرتفاع وحدة المعالجة المركزية بسبب أمر عرض كبير (show tech-support) أو عند تمكين الكثير من أوامر تصحيح الأخطاء، وهو ما يفرض إرسال الكثير من واجهة سطر الأوامر (CLI) عبر جلسة SSH.

• SNMP: قد يرجع السبب في ذلك إلى وكيل SNMP الذي يستغرق فترة طويلة من الوقت لمعالجة طلب، وبالتالي يتسبب في وحدة المعالجة المركزية (CPU) العالية. غالبًا ما يكون هناك سببان محتملان وهما قواعد معلومات الإدارة (MIB) التي يتم استقصائها، أو جداول المسار و/أو ARP التي يتم الاستطلاع بشأنها بواسطة NMS.

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

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

أوامر إضافية

فيما يلي قائمة بالأوامر الإضافية المفيدة الأخرى المطلوب استخدامها والتي يتم فرزها حسب المعالج الذي ترتبط به:

معالج المسار

• <show process cpu history>
  • يوفر رسمًا بيانيًا لمحفوظات وحدة المعالجة المركزية (CPU) على مدار آخر 60 ثانية ودقائق و 72 ساعة
• <show process process_ID>
  • معلومات مفصلة عن ذاكرة العملية الفردية وتخصيصات وحدة المعالجة المركزية
• <show platform software infrastructure punt>
  • يوفر معلومات عن جميع حركات المرور التي يتم توجيهها إلى RP
• <show platform software status control-processor brief>
  • تفاصيل حمل وحدة المعالجة المركزية و"سلامتها"، بالإضافة إلى تفاصيل إحصائيات الذاكرة والوحدة
• <show platform software process slot r0|r1 monitor>
  • تفاصيل العمليات المختلفة وتخصيصات وحدة المعالجة المركزية والذاكرة الخاصة بها على الوحدة المحددة
• <monitor platform software process r0|r1>
  • يوفر موجزًا مباشرًا يقوم بتحديث العمليات عند استخدام وحدة المعالجة المركزية (CPU)
  • يتطلب إدخال الأمر "terminal terminal-type" في وضع التكوين العام أولاً ليعمل بشكل صحيح

معالج الخدمات المضمنة

• <show platform software process list fp active summary>
  • يعرض تفاصيل ملخص جميع العمليات التي يتم تشغيلها على وحدة المعالجة المركزية (CPU)، بالإضافة إلى متوسط الحمل
• <show platform software process slot f0|f1 monitor>
  • تفاصيل العمليات المختلفة وتخصيصات وحدة المعالجة المركزية والذاكرة الخاصة بها على الوحدة المحددة
• <monitor platform software process f0|f1>
  • يوفر موجزًا مباشرًا يقوم بتحديث العمليات كما هي وتستخدم وحدة المعالجة المركزية
  • يتطلب إدخال الأمر "terminal terminal-type" في وضع التكوين العام أولاً ليعمل بشكل صحيح