إستخدام عالي لوحدة المعالجة المركزية (CPU)

المقدمة

يوضح هذا المستند الكيفية التي قد تعمل بها أنشطة Unified Contact Center Express (UCCX)، التي تتطلب الوصول إلى قاعدة بيانات UCCX المحلية، ببطء. وهو يتسبب في تحميل صفحات AppAdmin ببطء، واستكمال AppAdmin لوقت طويل لتأثيره، وتأخير في الاستجابة لاستعلام لوحة الحائط، وعجز "إدارة القوى العاملة" عن الاستعلام عن بيانات UCCX، ومشاكل أخرى تتعلق بالأداء والاستقرار.

يظهر الأمر show process load، الذي تم إدخاله في CLI، أن uccxoninit يستهلك كمية كبيرة من وحدة المعالجة المركزية. تمثل عملية UCCXONINIT مثيل قاعدة بيانات UCCX Informix التي تعمل على خادم UCCX.

تمت المساهمة من قبل سريدهار تشاندراسيخاران، وريان لافاونتن، وبن ووللاك، مهندسي TAC من Cisco.

معلومات الميزة

محرك قاعدة البيانات الذي يدعم تطبيق UCCX هو Informix من IBM. يتم تخزين التكوين والمعلومات التاريخية التي تتم إضافتها إلى صفحة AppAdmin الخاصة ب UCCX ويتم إنتاجها بواسطة تطبيق UCCX في مثيل UCCX Informix.

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

يتم توضيح معلومات المستخدم وأذونات كل مستخدم والغرض المقصود من كل مستخدم هنا:

• UCCXhruser - يختار هذا المستخدم أذونات للعديد من جداول التكوين والجداول التاريخية في قاعدة بيانات UCCX ويجب إستخدامه فقط لإعداد تقارير تاريخية مخصصة وإدارة القوى العاملة الموحدة من Cisco (WFM). قد تقوم الاستعلامات والإجراءات المخزنة التي ينفذها هذا المستخدم بإجراء استعلامات معقدة وطويلة الأمد. نظرا لملف تعريف أحد مستخدمي WFM أو أحد التقارير التاريخية النموذجية، يجب عدم تنفيذ هذه الاستعلامات والإجراءات المخزنة بشكل متكرر كما هو الحال بالنسبة لتطبيق اللوحة الخلفية.
  
  على الرغم من أن العديد من تطبيقات اللوحة الخلفية تتطلب بيانات ضمن الجداول التاريخية والتكوينية التي يمكن ل UCCXhruser الوصول إليها، إلا أنه ليس من المدعوم تقنيا إستخدام هذا المستخدم لتنفيذ استعلامات معقدة ومتكررة ضد قاعدة بيانات UCCXxDatabase لأغراض تطبيق لوحة حائط.
• عمالة uccxworkforce - يتمتع مستخدم UCCXworkforce بحق الوصول إلى جداول الفريق والمورد والمشرف ويجب إستخدامه لإدارة الجودة الموحدة من Cisco (QM). يجب أن تستخدم إدارة القوى العاملة UCCXxhruser لأنها تتطلب الوصول إلى جداول البيانات التاريخية التي لا يمكن الوصول إليها بواسطة المستخدم UCCXworkforce.

• لوح الطباعة الموحد - يملك هذا المستخدم أذونات التحديد فقط على جداول قاعدة البيانات في الوقت الفعلي التي تحتوي على لقطات لإحصائيات في الوقت الفعلي المكتوبة من ذاكرة محرك UCCX. تعني أذونات التحديد المقيدة بالجدولين RTCSQsSummary وRTICDStCredentials أن UCCXXwallboard يجب إستخدامه لاستعلام قاعدة بيانات UCCX بشكل متكرر باستخدام استعلامات بسيطة غير معقدة يقصد الحصول عليها من تطبيق لوحة حائط.

منهجية أستكشاف الأخطاء وإصلاحها

في UCCX الإصدار 10.0 والإصدارات الأحدث، أدخل قاعدة بيانات utils uccx dbperf ابدأ <totalHours> <interval>الأمر لبدء تتبع الأداء على قاعدة بيانات UCCX. تحدد وسيطة الفاصل الزمني الموجودة في هذا الأمر دورية مجموعة التتبع وتحدد وسيطة totalHours إجمالي الوقت الذي يتم فيه تشغيل التتبع قبل تعطيله. هذه المعلمات إختيارية. إذا لم يتم تحديدها عند تنفيذ الأمر، فإنه يتم إستخدام القيم الافتراضية وهي 20 دقيقة و 10 ساعات.

على سبيل المثال، أدخل الأمر utils uccx database dbperf start 24 30 لتمكين تتبع الأداء على قاعدة البيانات وجمع البيانات حول إحصائيات الأداء كل 30 دقيقة لمدة 24 ساعة.

تطبع إرشادات تجميع البيانات التي تم الحصول عليها بواسطة الأمر CLI في إخراج الأمر.

بعد TotalHours المحددة، يتم إيقاف تجميع البيانات تلقائيا. دخلت in order to يدويا إيقاف المعطيات مجموعة، القاعدة utils uccx قاعدة معطيات dbperf stop أمر.

إذا كان إصدار UCCX هو الإصدار 9.0(2) أو إصدار أقدم و قاعدة بيانات uTILS uccx dbperf القيادة غير متوفرة، اتصل بمركز المساعدة التقنية (TAC) للحصول على مزيد من المساعدة.

سيقوم TAC بتنفيذ البرنامج النصي dbperf.sh المرفق بمعرف تصحيح الأخطاء من Cisco CSCuc68413 يدويا مع الوصول إلى حساب الدعم عن بعد.

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

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

تحليل البيانات

تظهر السجلات التي تم تجميعها بواسطة تنفيذ البرنامج النصي dbperf ل onstat -g ses0 الاستعلامات النشطة التي يتم إصدارها مقابل قاعدة بيانات UCCX. عادة ما يكون إرتفاع مستوى وحدة المعالجة المركزية (CPU) في عملية UCCXONINIT نتيجة لاستعلامات معقدة تستغرق وقتا طويلا لتنفيذها. الهدف هو تحديد الاستعلامات التي تستهلك معظم الموارد، وتحديد العميل المصدر لهذه الاستعلامات، وتعطيل الاستعلامات من العميل لحلها فورا، وتحسين الاستعلامات التي يتم تشغيلها لمدة طويلة للحل الدائم.

في السجلات التي تم تجميعها بواسطة البرنامج النصي dbperf، ابحث عن الاستعلامات التي تتسبب على الأرجح في حدوث تقلبات كبيرة في وحدة المعالجة المركزية (CPU) أو إستهلاك مرتفع ومستمر لوحدة المعالجة المركزية (CPU) بواسطة عملية uccxoninit.

الاستعلامات المشبوهة:

• يتم إصدارها من جلسات العمل المتصلة ب UCCXHRUSER - كما هو موضح مسبقا، يتمتع المستخدم بامتيازات إختيار معلومات من عدد كبير من جداول التكوين والجداول التاريخية. ونتيجة لذلك، يمكن إنشاء استعلامات معقدة وطويلة الأمد قيد التشغيل عبر جداول متعددة ويمكن أن يكون لها تأثير على الأداء على قاعدة بيانات UCCX. على الرغم من أن الوصول إلى الجداول ضمن قاعدة بيانات UCCCX وUCXoWorkforce ليس مطلقا، إلا أنه من غير المرجح أن تكون الاستعلامات المعقدة التي تتسبب في تأثير الأداء الذي يصدره هؤلاء المستخدمون. بالإضافة إلى ذلك، فإن الاستعلامات الصادرة عن UCCXhrcare من قبل UCCX History Reporting Client (HRC) أو Cisco Unified Intelligence Center (CUIC) مقابل قاعدة بيانات UCCX. هذه الاستعلامات ثابتة ولا يمكن تعديلها، وقد تمت كتابة الاستعلامات، مع المؤشرات ذات الصلة، واختبارها، وضبطها للحد الأدنى من تأثير الأداء.
• إجراء استعلامات مكثفة على الجداول التاريخية - الاستعلامات التي تتطلب قاعدة بيانات UCCX للقيام بعمليات ربط متعددة عبر الجداول أو تحديد كميات كبيرة من المعلومات أو العمل على حقول غير مفهرسة قد تتسبب في حدوث تأثيرات على الأداء في قاعدة بيانات UCCX.

يتم عرض مثال مع استعلام معقد يتضمن جدول الموارد البشرية الذي يتم تشغيله كمستخدم UCCXhhruser هنا:

session                                      #RSAM    total      used       dynamic
id       user     tty      pid      hostname threads  memory     memory     explain
435050   uccxhrus WBBOX 836      10.16.5. 1        90112      80712      off

...................

Current SQL statement :
  SELECT x.resourceName, t.eventType, x.datetime, x.extension FROM ( SELECT
    t1.resourceID, t1.resourceName, t1.extension, MAX(t2.eventDateTime) AS
    datetime FROM  Resource AS  t1, AgentStateDetail AS  t2 WHERE  t2.agentID
    = t1.resourceID AND t1.assignedTeamID  = 21 and t1.active GROUP BY
    t1.resourceID, t1.resourceName, t1.extension ) AS  x, AgentStateDetail AS
    t  WHERE  t.agentID  = x.resourceID AND t.eventDateTime  = x.datetime
    ORDER BY  x.resourceName

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

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

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

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

في مخرجات البرنامج النصي dbperf، يمكن رؤية استعلام الإزالة. يجب أن يكون هذا الاستعلام هو الاستعلام الوحيد الذي قام المستخدم uccxuser باستدعاء الإجراء المخزن sp_purge.

session                                      #RSAM    total      used       dynamic
id       user     tty      pid      hostname threads  memory     memory     explain
5628     uccxuser -        -1       CC-EXPR- 1        544768     523408     off

 

Current SQL statement in procedure db_cra:sp_purge
   proc-counter 0x0x4ccf9260 opcode SQL


delete from contactroutingdetail
  where (exists
    (select 1
      from contactcalldetail as ccdr
      where (and (and (and (and (and (= contactroutingdetail.sessionid, 
ccdr.sessionid), (= contactroutingdetail.nodeid, ccdr.nodeid)), 
(= contactroutingdetail.sessionseqnum, ccdr.sessionseqnum)), 
(= contactroutingdetail.profileid, ccdr.profileid)), (>= ccdr.enddatetime, 
p_purgefrom)), (< ccdr.enddatetime, p_purgeto))));

مشاكل مشتركة

استنادا إلى الخبرة الحديثة في هندسة التطوير من Cisco TAC و Cisco، فإن هذه هي المشكلات الأكثر شيوعا التي تتسبب في إستخدام عال لوحدة المعالجة المركزية على عملية uccxoninit:

• يتصل عميل في المؤسسة بمستخدم uccxHruser ويقوم بتشغيل استعلامات معقدة متكررة على جداول اللوحة الخلفية (RTICDStics و RTCSQsSummary) المرتبطة بالجداول التاريخية من أجل توفير حل لوحة خلفية أو حل تقرير مخصص. بالنسبة لاستخدام اللوحة الخلفية، أستخدم مستخدم uccxwallboard فقط وحد الاستعلامات إلى جداول الوقت الفعلي. لا يتم دعم إمكانية الاستعلام عن الجداول التاريخية أو جداول التكوين من اللوحة الخلفية أو بالتردد المماثل للوحات الخلفية.
• يحاول العميل تنفيذ تقارير تاريخية مخصصة على العقدة الأساسية النشطة بدلا من العقدة الثانوية. قم فقط بتنفيذ الإجراءات المخزنة، إما المخصصة أو الافتراضية، التي تنتج تقارير قديمة على عقدة الاستعداد. يقوم CUIC و HRC بتنفيذ الاستعلامات على عقدة الاستعداد بشكل افتراضي، ولكن عند تطوير تقرير تاريخي مخصص، يكون للمطور خيار على أي عقدة لتشغيل هذه الاستعلامات أو تنفيذ هذه الإجراءات المخزنة.
• تصدر Cisco Workforce Management (WFM) استعلاما معقدا في جدول ContactRoutingDetail لمحاولة التصفية على حقل startDateTime. لا يتم إنشاء أي فهرس على هذا الحقل في هذا الجدول بشكل افتراضي، لذا فإن أداء هذا الاستعلام ضعيف. يصدر WFM هذا الاستعلام بشكل دوري في محاولة لمزامنة البيانات من UCCX إلى WFM. التقطت هذا إصدار في cisco بق id CSCtz23710 وحللت في WFM إطلاق 9.0(1)SR4. يجب على العملاء الذين يواجهون هذه المشكلة الترقية إلى إصدار WFM يحتوي على إصلاح لمعرف تصحيح الأخطاء من Cisco CSCtz23710.
• تم تعديل حدود الإزالة بحيث تحاول عملية الإزالة المجدولة التالية إزالة كمية كبيرة من البيانات. بدلا من تعديل معلمات الإزالة بشكل ملحوظ في تحديث واحد، يتم إجراء تعديلات جدول الإزالة بشكل متكرر، مع إجراء بضعة أيام بين تعديلات تكوين الإزالة. وهذا يسمح لعملية الإزالة بإزالة مجموعات أصغر من البيانات في كل مرور، مما يحسن أداء عملية الحذف.
• جدول DialList كبير للغاية. يقوم جدول DialList بتخزين جميع جهات الاتصال التي تم تحميلها إلى الحملات الصادرة. في الإصدارين 8.0 و 8.5 من UCCX، بعد تحميل ملايين السجلات إلى الحملات الصادرة، ينتج عن ذلك مشاكل في الأداء عند الاستعلام عن الجدول (مما يتسبب في إرتفاع وحدة المعالجة المركزية في عملية UCCXONINIT وتباطؤ تحميل صفحة AppAdmin). للحد من مشاكل الأداء، افتح حالة مركز المساعدة الفنية لتثبيت برنامج نصي لمهمة cron يقوم بتنظيف جدول DialList. في الإصدار 9.0 من UCCX، تمت إضافة فهرس إلى هذا الجدول للحصول على استعلامات أكثر فعالية من AppAdmin في محاولة لتحسين الأداء. وقد حل هذا التغيير المشكلة في جميع الحالات باستثناء الحالات الأكثر تطرفا. في الإصدار 10.0 من UCCX، تم تقسيم قائمة الطلب إلى جدولين، واحد للاتصالات النشطة وآخر للاتصالات التاريخية، مما يوفر حلا شاملا لهذه المشكلة.