Informix高CPU利用率

簡介

本文檔介紹需要本地UCCX資料庫訪問的Unified Contact Center Express(UCCX)活動可能會如何緩慢執行。它導致AppAdmin頁面載入緩慢，對AppAdmin的更新需要較長時間才能生效，牆板查詢響應延遲，Workforce Manager無法查詢UCCX資料，以及其他效能和穩定性問題。

在CLI中輸入的show process load指令顯示ucxoninit消耗大量CPU。ucxoninit進程表示在UCCX服務器上運行的UCCX Informix資料庫實例。

作者：Sridhar Chandrasekharan、Ryan LaFountain和Ben Wollak，思科TAC工程師。

功能資訊

支援UCCX應用程式的數據庫引擎是IBM的Informix。新增到UCCX的AppAdmin頁面並由UCCX應用程式生成的配置和歷史資訊儲存在UCCXInformix例項中。

UCCX應用程式提供三個使用者，可用於直接訪問UCCX資料庫，以提取用於牆板應用程式、品質管理、員工管理和自定義歷史報告的資訊。

使用者資訊、每個使用者的許可權以及每個使用者的預期用途如下所述：

• ucxhruser — 此使用者對UCCX資料庫中的許多配置和歷史表具有選擇權限，應僅用於自定義歷史報告和Cisco Unified Workforce Management(WFM)。 此使用者執行的查詢和儲存過程可能會執行複雜、長時間運行的查詢。由於典型的歷史報告或WFM使用者的配置檔案，這些查詢和儲存過程不應該像牆板應用程式那樣頻繁執行。
  
  儘管許多牆板應用程式需要包含在ucxhruser有權訪問的配置和歷史表中的資料，但技術上不支援使用該使用者對UCCX資料庫執行複雜、頻繁的查詢，以用於牆板應用程式的目的。
• ucxworkforce - ucxworkforce使用者有權訪問「團隊」、「資源」和「主管」表，應該用於Cisco Unified Quality Management(QM)。 Workforce Management應使用ucxhruser，因為它需要訪問ucxworkforce使用者不可訪問的歷史數據表。

• ucxwallboard  — 此使用者僅對包含從UCCX引擎記憶體中寫入的即時統計資訊的快照的即時資料庫表具有選擇許可權。僅限於RTCSQsSummary和RTICDStatistics表的select許可權意味著ucxwallboard使用者應該用於頻繁使用旨在由牆板應用程式來源的簡單、非複雜查詢來查詢UCCX資料庫。

故障排除方法

在UCCX 10.0及更高版本中，輸入utils uccx database dbperf start <totalHours> <interval> 命令以在UCCX資料庫上開始效能跟蹤。此命令中的interval引數確定跟蹤收集的週期，而totalHours引數確定禁用跟蹤前運行跟蹤的總時間。這些引數是可選的。如果在執行命令時未指定這些值，則使用預設值20分鐘和10小時。

例如，輸入utils uccx database dbperf start 24 30 命令以啟用資料庫的效能跟蹤，並每30分鐘收集一次效能統計資訊，持續24小時。

用於收集CLI命令獲取的資料的指令將列印在命令輸出中。

在給定totalHours後，資料收集將自動停止。要手動停止資料收集，請輸入utils uccx database dbperf命令。

如果UCCX版本是9.0(2)版或更低版本，則 實用程式uccx資料庫dbperf 命令不可用，請聯絡技術支援中心(TAC)以獲得進一步幫助。

TAC將使用遠端支援帳戶存取，手動執行附加到思科錯誤ID CSCuc68413的dbperf.sh指令碼。

當您確定何時開始手動執行指令碼或通過CLI命令執行指令碼、週期和總時間時，請確保使用 ucxoninit 流程在這些時期波動很大，或波動率很高，以便收集必要的資訊用於根本原因分析。

此外，定期輸入show process load 命令以確定CPU波動的時間，以便關聯由dbperf跟蹤指令碼收集的日誌。

資料分析

dbperf指令碼執行onstat -g ses 0時收集的日誌顯示針對UCCX資料庫發出的活動查詢。ucxoninit進程的CPU使用率較高，這通常是需要長時間執行複雜查詢的結果。目標是確定佔用最多資源的查詢，確定這些查詢的源客戶端，禁用來自客戶端的查詢以立即解決問題，並最佳化長時間運行的查詢以永久解決問題。

在dbperf指令碼收集的日誌中，查詢最可能導致ucxoninit進程的CPU大幅波動或持續高CPU消耗的查詢。

可疑查詢：

• 從連線為ucxhruser的會話發出 — 如前所述，ucxhruser具有從大量配置和歷史表中選擇資訊的許可權。因此，可以構建跨多個表長時間運行的複雜查詢，並且可能會對UCCX資料庫產生效能影響。雖然不是絕對的，ucxwallboard和ucxworkforce使用者對UCCX資料庫內的表的訪問是如此有限，不太可能發出導致效能影響的複雜查詢。此外，由UCCX歷史報告客戶端(HRC)或Cisco Unified Intelligence Center(CUIC)針對UCCX資料庫發佈的ucxhrcare發出的查詢。這些查詢是靜態的，無法修改，並且已編寫、測試和調整這些查詢以及相關的指標，以使效能影響最小。
• 對歷史表執行密集查詢 — 要求UCCX資料庫跨表執行多個聯接、選擇大量資訊或在未索引欄位上操作的查詢可能會對UCCX資料庫造成效能影響。

以下是包含以ucxhruser形式運行的HR表的複雜查詢示例：

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

上例顯示了一個由ucxhruser輸入的複雜查詢，該查詢來自主機WBBOX，如果它經常輸入或在上一個查詢返回結果之前定期輸入，則可能會對UCCX資料庫造成效能影響。

儘管很少見,UCCX數據庫效能也會降低(以及 ucxoninit 由於內建的清除流程，流程波動或保持較高)。清除過程旨在從UCCX資料庫中的配置和歷史表中刪除資料，以便保持資料庫的大小。可以根據資料庫的大小或資料庫中包含的最早記錄來計劃清除。

當清除進程運行時，用一個查詢刪除資料。此操作不會根據要移除的記錄量重複執行。這意味著如果清除檢測到大量必須刪除的資料，它會發出一個查詢來嘗試刪除這些資料。

從UCCX AppAdmin頁面修改清除計畫或引數，以便計劃清除以刪除大量資料，這可能會導致在下一次計劃清除時此單個查詢需要大量時間才能完成。因此，它會提高資料庫例項的CPU利用率。

在dbperf指令碼的輸出中，可以看到清除查詢。它應該是使用者ucxuser輸入的唯一呼叫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 Development Engineering經驗，以下是ucxoninit流程中導致CPU使用率較高的最常見問題：

• 企業中的客戶端以ucxhruser身份連線，對加入歷史表的牆板表（RTICDStatistics和RTCSQsSummary）運行頻繁的複雜查詢，以提供牆板或自定義報告解決方案。對於牆板使用，僅使用ucxwallboard使用者並限制對即時表的查詢。不支援從牆板或以類似牆板的頻率查詢歷史表或配置表。
• 客戶端嘗試在活動主節點而不是輔助節點上執行自定義歷史報告。只執行在備用節點上生成歷史報告的儲存過程（自定義或預設）。預設情況下，CUIC和HRC在備用節點上執行查詢，但是在開發自定義歷史報表時，開發人員可以選擇運行這些查詢或執行這些儲存過程的節點。
• Cisco Workforce Management(WFM)在ContactRoutingDetail表上發出複雜的查詢，以嘗試在startdatetime欄位上進行篩選。預設情況下，不會在此表中的該欄位上建立索引，因此該查詢的效能較差。WFM定期發出此查詢，以嘗試將資料從UCCX同步到WFM。此問題已擷取在Cisco錯誤ID CSCtz23710中，並在WFM版本9.0(1)SR4中解決。遇到此問題的客戶應升級至包含思科錯誤ID CSCtz23710的修正程式的WFM版本。
• 清除閾值被修改，以便下一次排程的清除嘗試刪除大量資料。清除計畫修改不是在單個更新中顯著地修改清除引數，而是反複進行，在清除配置修改之間需要幾天時間。這允許清除進程在每次傳遞中移除更小的資料集，從而提高刪除操作的效能。
• DialingList表非常大。DialingList表儲存上傳到出站活動的所有聯絡人。在UCCX版本8.0和8.5中，在將數百萬條記錄上傳到出站活動後，效能問題導致查詢表（這會導致ucxoninit進程的CPU使用率高和AppAdmin頁面載入緩慢）。 為了緩解效能問題，請開啟一個TAC案例，以安裝cron作業指令碼，該指令碼用於清除DialingList表。在UCCX版本9.0中，向此表新增了一個索引，用於從AppAdmin進行更有效的查詢，以嘗試提高效能。除最極端情況外，此更改解決了所有問題。在UCCX版本10.0中，撥號清單已拆分為兩個表，一個用於活動聯絡人，另一個用於歷史聯絡人，這樣可以全面解決此問題。