يقدم هذا المستند خطوات للمساعدة في مراقبة المشكلات المتعلقة باستخدام المعالج العالي على Cisco Unified Communications Manager 6.0 باستخدام RTMT واستكشاف أخطائها وإصلاحها.
cisco يوصي أن يتلقى أنت معرفة من هذا موضوع:
مدير الاتصالات الموحدة من Cisco
تستند المعلومات الواردة في هذه الوثيقة إلى بنود جدول الأعمال التالية:
تستند المعلومات الواردة في هذا المستند إلى مدير الاتصالات الموحدة من Cisco، الإصدار 6.0.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.
راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.
يمكن أن يكون إستخدام RTMT لعزل المشاكل المحتملة باستخدام وحدة المعالجة المركزية خطوة مفيدة جدا لاستكشاف الأخطاء وإصلاحها.
تمثل هذه المصطلحات إستخدام وحدة المعالجة المركزية (CPU) الخاصة ب RTMT وتقارير صفحة الذاكرة:
٪النظام: النسبة المئوية لاستخدام وحدة المعالجة المركزية (CPU) التي حدثت أثناء التنفيذ على مستوى النظام (kernel)
٪user: النسبة المئوية لاستخدام وحدة المعالجة المركزية (CPU) التي حدثت أثناء التنفيذ على مستوى المستخدم (التطبيق)
٪IOwAit: النسبة المئوية للوقت الذي كانت فيه وحدة المعالجة المركزية خاملة أثناء انتظارها لطلب إدخال/إخراج قرص متميز
٪SoftIRQ: النسبة المئوية للوقت الذي يقوم فيه المعالج بتنفيذ معالجة IRQ المؤجلة (على سبيل المثال، معالجة حزم الشبكة)
٪IRQ النسبة المئوية للوقت الذي يقوم فيه المعالج بتنفيذ طلب المقاطعة، والذي تم تعيينه للأجهزة للمقاطعة، أو يرسل إشارة إلى الكمبيوتر عند الانتهاء من المعالجة
يقوم CPUPeging/CallProcessNodeCPUPeging بمراقبة إستخدام وحدة المعالجة المركزية (CPU) استنادا إلى الحدود التي تم تكوينها:
ملاحظة: ٪CPU يتم حسابها على أنها ٪system + ٪user + ٪nice + ٪ioWait + ٪softirq + ٪irq
تتضمن رسائل التنبيه ما يلي:
٪system و٪user و٪nice و٪ioWait و٪softirq و٪irq
العملية التي تستخدم أكثر وحدات المعالجة المركزية (CPU)
العمليات التي تنتظر سكون القرص غير القابل للانقطاع
يمكن أن تظهر التنبيهات الخاصة بتثبيت وحدة المعالجة المركزية (CPU) في RTMT بسبب الاستخدام الأعلى لوحدة المعالجة المركزية (CPU) مقارنة بما تم تعريفه كمستوى للعلامة المائية. نظرا لأن CDR عبارة عن تطبيق مكثف لوحدة المعالجة المركزية (CPU) عند تحميله، فتحقق مما إذا كنت تتلقى التنبيهات في نفس الفترة الزمنية التي تم فيها تكوين وحدة المعالجة المركزية (CDR) لتشغيل التقارير. في هذه الحالة، أنت يستطيع تحتاج أن يزيد العتبة قيمة على RTMT. ارجع إلى التنبيهات للحصول على مزيد من المعلومات حول تنبيهات RTMT.
إذا كان ٪system و/أو ٪user في حالة إرتفاع كاف لإنشاء تنبيه تسجيل دخول المعالج، فتحقق من رسالة التنبيه لمعرفة العمليات التي تستخدم معظم وحدات المعالجة المركزية (CPU).
ملاحظة: انتقل إلى صفحة عملية RTMT وفرز حسب ٪CPU لتحديد عمليات وحدة المعالجة المركزية العالية.
ملاحظة: لتحليل ما بعد الوفاة، يتتبع سجل PerfMon الخاص باستكشاف أخطاء RIS وإصلاحها العملية التي تستخدم وحدة المعالجة المركزية (CPU) ٪RPomtem وتعقبها على مستوى النظام.
يشير إرتفاع ٪IOwAit إلى وجود أنشطة إدخال/إخراج عالية بالقرص. تأملوا في ما يلي:
يعود IOait إلى تبادل الذاكرة بشكل مكثف.
تحقق من وقت ٪CPU الخاص بتقسيم التبديل لمعرفة ما إذا كان هناك مستوى مرتفع من نشاط تبديل الذاكرة. نظرا لأن ذاكرة الوصول العشوائي (RAM) من الجيل الثاني على الأقل متوفرة لدى المجموعة، فمن المرجح أن يرجع إستبدال الذاكرة إلى حدوث تسرب في الذاكرة.
يعود IOait إلى نشاط قاعدة البيانات.
يعتبر DB بشكل أساسي هو الوحيد الذي يصل إلى القسم النشط. إذا كان وقت وحدة المعالجة المركزية (CPU) الخاص بالقسم النشط مرتفعا، فمن المحتمل أن يكون هناك الكثير من نشاط قاعدة البيانات.
القسم الشائع (أو قسم السجل) هو الموقع الذي يتم فيه تخزين ملفات التتبع والسجل.
ملاحظة: تحقق مما يلي:
Trace & Log Central — هل هناك أي نشاط لجمع التتبع؟ إذا تأثرت معالجة المكالمة (أي، CodeYellow)، فقم بتعديل جدول مجموعة التتبع. أيضا، إذا كان الخيار zip مستخدم، قم بإيقاف تشغيله.
إعداد التتبع - على المستوى التفصيلي، ينتج CallManager قدرا كبيرا من التتبع. إذا كان ٪IOwAit و/أو CCM عاليا في حالة CodeYellow وكان إعداد تتبع خدمة CallManager عند Detail، فحاول تغييره إلى "خطأ".
لا توجد طريقة مباشرة لمعرفة إستخدام ٪IOwAit لكل عملية. حاليا، أفضل طريقة هي التحقق من العمليات التي تنتظر على القرص.
إذا كان ٪IOwAit مرتفعا بشكل كاف لإحداث تنبيه تسجيل حالة المعالج، فتحقق من رسالة التنبيه لتحديد العمليات التي تنتظر إدخال/إخراج القرص.
انتقل إلى صفحة عملية RTMT وفرز حسب الحالة. تحقق من وجود عمليات في حالة السكون على القرص غير القابل للانقطاع. عملية SFTP التي تستخدمها TLC للمجموعة المجدولة هي في حالة سكون القرص غير القابل للانقطاع.
ملاحظة: يمكن تنزيل ملف سجل PerfMon الخاص باستكشاف أخطاء RIS وإصلاحها لفحص حالة العملية لفترات زمنية أطول.
في أداة مراقبة الوقت الفعلي، انتقل إلى النظام > أدوات > تتبع > تتبع & log central.
انقر نقرا مزدوجا فوق تجميع الملفات واختر التالي.
أختر PerfMonLog لمجمع بيانات Cisco RIS واختر Next.
في حقل وقت التجميع، قم بتكوين الوقت المطلوب لعرض ملفات السجل للفترة المعنية. في حقل خيارات تنزيل الملفات، استعرض إلى مسار التنزيل لديك (وهو الموقع الذي يمكنك من خلاله تشغيل "مراقبة أداء Windows" لعرض ملف السجل)، واختر ملفات Zip، واختر إنهاء.
لاحظ تقدم عملية تجميع الملفات ومسار التنزيل. لا يجب الإبلاغ عن أية أخطاء هنا.
عرض ملفات سجل الأداء باستخدام أداة مراقبة أداء Microsoft. أختر ابدأ > إعدادات > لوحة التحكم > أدوات الإدارة > الأداء.
في نافذة التطبيق، انقر بزر الماوس الأيمن واختر خصائص.
أختر صفحة المصدر في شاشة خصائص مراقبة النظام. أختر ملفات السجل: كمصدر بيانات، وانقر زر إضافة.
استعرض الدليل الذي قمت بتنزيل ملف سجل PerfMon فيه واختر ملف Perfmon csv. يتضمن ملف السجل اصطلاح التسمية هذا:
PerfMon_<node>_<month>_<day>_<year>_<hour>_<minute>.csv؛ على سبيل المثال، PerfMon_10.89.35.218_6_20_2005_11_27.csv.
طقطقة يطبق.
انقر فوق زر النطاق الزمني. لتحديد النطاق الزمني في ملف سجل PerfMon الذي تريد عرضه، اسحب الشريط إلى أوقات البداية والنهاية المناسبة.
لفتح شاشة إضافة عدادات، انقر فوق علامة التبويب بيانات وانقر فوق إضافة. من المربع المنسدل لكائن الأداء، أضف عملية. أختر حالة العملية وانقر كل المثيلات. عندما تنتهي من خيارات العدادات، انقر إغلاق.
تلميحات حول كيفية عرض السجل:
ضبط القياس الرأسي للرسمة البيانية إلى الحد الأقصى 6.
ركز على كل عملية وانظر إلى القيمة القصوى التي تبلغ 2 أو أكثر.
حذف العمليات التي ليست في وضع السكون غير القابل للانقطاع على القرص.
أستخدم خيار الإبراز.
ملاحظة: حالة العملية 2 = السكون غير القابل للانقطاع على القرص موضع شك. إمكانات الحالة الأخرى هي صفر تشغيل، و 1 نوم، و 2 نوم غير متقطع على القرص، و 3-زومبي، و 4-تتبع أو توقف، و 5-ترحيل، و 6-غير معروف
يتم إنشاء تنبيه الرمز الأصفر عندما تدخل خدمة CallManager في حالة الرمز الأصفر. لمزيد من المعلومات حول حالة الرمز الصفراء، ارجع إلى تقييد المكالمات وحالة الرمز الصفراء. يمكن تكوين تنبيه CodeYellow لتنزيل ملفات التتبع لأغراض أستكشاف الأخطاء وإصلاحها.
يمثل عداد AverageExpectedDelay متوسط التأخير المتوقع الحالي لمعالجة أي رسالة واردة. إذا كانت القيمة أعلى من القيمة المحددة في معلمة الخدمة "زمن انتقال الإدخال الأصفر للتعليمات البرمجية"، يتم إنشاء تنبيه CodeYellow. يمكن أن يكون هذا العداد مؤشرا أساسيا واحدا لأداء معالجة المكالمة.
من الممكن أن يدخل CallManager في حالة "الرمز الأصفر" بسبب نقص موارد المعالج عندما يكون إجمالي إستخدام وحدة المعالجة المركزية (CPU) حوالي 25-35 بالمائة فقط في مربع يحتوي على 4 معالجات افتراضية.
ملاحظة: مع تشغيل برنامج Hyper-Threading، يتميز الخادم المزود بمعالجين فيزيائيين بأربعة معالجات افتراضية.
ملاحظة: كذلك، في ملقم يحتوي على معالجين، يمكن إستخدام CodeYellow بنسبة 50 بالمائة تقريبا من إجمالي إستخدام وحدة المعالجة المركزية.
إذا قام RTMT بإرسال حالة الخدمة إلى أسفل. Cisco Messaging Interface. Alert، يجب عليك إلغاء تنشيط خدمة واجهة المراسلة من Cisco إذا لم يتم دمج CUCM مع نظام المراسلة الصوتية للجهة الخارجية. إذا قمت بتعطيل خدمة واجهة المراسلة من Cisco، فإنها تتوقف عن إجراء المزيد من التنبيهات من RTMT.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
30-Jan-2009 |
الإصدار الأولي |