Informix高CPU利用率

简介

本文档介绍需要本地UCCX数据库访问的Unified Contact Center Express(UCCX)活动如何能够缓慢执行。它会导致AppAdmin页面加载缓慢，更新到AppAdmin需要很长时间才能生效，延迟对墙板查询的响应，Workforce Manager无法查询UCCX数据，以及其他性能和稳定性问题。

在CLI中输入的命令show process load显示uccxonit 消耗了大量CPU。uccxonit进程表示在UCCX服务器上运行的UCCX Informix 数据库实例。

作者：Sridhar Chandrasekharan、Ryan LaFountain和Cisco TAC工程师Ben Wollak。

功能信息

支持UCCX应用程序的数据库引擎是IBM的Informix。添加到UCCX的AppAdmin页面并由UCCX应用程序生成的配置和历史信息存储在UCCX Informix实例中。

UCCX应用程序提供三个用户，可用于直接访问UCCX数据库，以便提取信息以用于壁板应用程序、质量管理、员工管理和自定义历史报告。

下面介绍了用户信息、每个用户的权限以及每个用户的预期用途：

• uccxhruser — 此用户对UCCX数据库中的许多配置和历史表具有选择权限，并且应仅用于自定义历史报告和思科统一员工管理(WFM)。 此用户执行的查询和存储过程可能执行复杂、长时间运行的查询。由于典型历史报告或WFM用户的配置文件，这些查询和存储过程不应像墙板应用程序那样频繁执行。
  
  虽然许多墙板应用程序需要包含在配置表和历史表中的数据，而uccxhruser有权访问这些表，但在技术上不支持使用此用户执行复杂、频繁的UCCX数据库查询，以用于墙板应用程序。
• uccxworkforce - uccxworkforce用户有权访问“团队”、“资源”和“管理引擎”表，并应用于思科统一质量管理(QM)。 Workforce Management应使用uccxhruser，因为它需要访问uccxworkforce用户无法访问的历史数据表。

• uccxwallboard  — 此用户仅对包含从UCCX引擎内存写入的实时统计信息快照的实时数据库表具有选择权限。受表RTCSQsSummary和RTICDStatistics限制的选择权限意味着uccxwallboard 用户应使用简单、非复杂的查询频繁地查询UCCX数据库，这些查询旨在由墙板应用程序提供。

故障排除方法

在UCCX 10.0版及更高版本中，输入utils uccx 数据库dbperf start <totalHours> <interval> 命令，以开始对UCCX数据库进行性能跟踪。此命令中的interval参数确定跟踪收集的周期性，而totalHours参数确定在禁用跟踪之前跟踪运行的总时间量。这些参数是可选的。如果在执行命令时未指定这些值，则使用默认值20分钟和10小时。

例如，输入utils uccx 数据库dbperf start 24 30 命令，以便在数据库上启用性能跟踪并在24小时内每30分钟收集一次有关性能统计信息的数据。

用于收集CLI命令获取的数据的说明会打印在命令输出中。

在给定totalHours后，数据收集将自动停止。要手动停止数据收集，请输入utils uccx dbperf stop命令。

如果UCCX版本为9.0(2)或更低版本， utils uccx数据库dbperf 命令不可用，请与技术支持中心(TAC)联系以获得进一步帮助。

TAC将手动执行dbperf.sh脚本，该脚本附加到Cisco Bug ID CSCuc68413，并具有远程支持帐户访问权。

当您确定何时手动或通过CLI命令启动脚本执行时，请确保周期和总时间，确保 uccxoninit 流程在这些期间波动较大或保持较高，以便收集进行根本原因分析所需的信息。

此外，定期输入show process load命令以确定CPU何时波动以关联dbperf跟踪脚本收集的日志。

数据分析

dbperf脚本执行onstat -g ses 0时收集的日志显示针对UCCX数据库发出的活动查询。uccxoninit进程上的高CPU通常是执行时间较长的复杂查询的结果。其目标是确定消耗最多资源的查询、确定这些查询的源客户端、禁用来自客户端的查询以立即解决问题，并优化长时间运行的查询以实现永久解决。

在dbperf脚本收集的日志中，查找最有可能导致CPU高波动或uccxonit进程持续高CPU消耗的查询。

可疑查询：

• 从连接为uccxhruser的会话发出 — 如前所述，uccxhruser具有从大量配置和历史表中选择信息的权限。因此，可以跨多个表构建复杂且运行时间较长的查询，并且可能对UCCX数据库产生性能影响。虽然uccxwallboard和uccxworkforce用户对UCCX数据库中表的访问权限非绝对，但不太可能出现导致这些用户发出的性能影响的复杂查询。此外，UCCX历史报告客户端(HRC)或Cisco统一情报中心(CUIC)对UCCX数据库发出的uccxhrcare查询。这些查询是静态的，无法修改，并且已编写、测试和调整了这些查询以及相关指示，以最大限度地降低性能影响。
• 在历史表上执行密集查询 — 要求UCCX数据库跨表执行多个联接、选择大量信息或在未索引字段上操作的查询可能会对UCCX数据库造成性能影响。

下面显示了一个复杂查询的示例，该查询涉及以uccxhruser形式运行的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

上例显示由源自主机WBBOX的uccxhruser输入的复杂查询，如果经常输入或在上一查询返回结果之前定期输入，则该查询可能会对UCCX数据库造成性能影响。

UCCX数据库性能虽然极少，但也会降低(以及 uccxoninit 进程波动或保持高)，这是内置清除过程的结果。清除过程旨在从UCCX数据库中的配置表和历史表中删除数据，以保持数据库的大小。可以根据数据库的大小或数据库中包含的最早记录来安排清除。

运行清除进程时，将使用一个查询删除数据。它不会根据要删除的记录量迭代完成。这意味着，如果清除检测到必须删除的大量数据，它会发出单个查询以尝试删除此数据。

修改UCCX AppAdmin页中的清除计划或参数以安排清除以删除大量数据可能会导致在下次计划清除时此查询需要大量时间才能完成。因此，它会提高数据库实例的CPU利用率。

在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和思科开发工程经验，以下是导致uccxoninit进程CPU使用率较高的最常见问题:

• 企业中的客户端作为uccxhruser连接，并在与历史表连接的壁板表（RTICDStatistics和RTCSQsSummary）上运行频繁的复杂查询，以提供壁板或自定义报告解决方案。对于墙板，请仅使用uccxwallboard用户，并将查询限制为实时表。不支持从墙板或以类似墙板的频率查询历史或配置表。
• 客户端尝试在活动主节点而不是辅助节点上执行自定义历史报告。只执行在备用节点上生成历史报告的自定义或默认存储过程。默认情况下，CUIC和HRC在备用节点上执行查询，但在开发自定义历史报告时，开发人员可以选择在哪个节点上运行这些查询或执行这些存储过程。
• Cisco Workforce Management(WFM)在ContactRoutingDetail表上发出复杂查询，以尝试在startdatetime字段上进行过滤。默认情况下，此表中的此字段上未创建索引，因此此查询的性能较差。WFM定期发出此查询，以尝试将数据从UCCX同步到WFM。此问题在Cisco Bug ID CSCtz23710中捕获，在WFM版本9.0(1)SR4中得到解决。遇到此问题的客户应升级到包含Cisco Bug ID CSCtz23710的修复的WFM版本。
• 清除阈值被修改，以便下次计划清除尝试删除大量数据。清除计划修改不是在单个更新中显着地修改清除参数，而是迭代地进行，在清除配置修改之间有几天。这允许清除过程在每次传递中删除较小的数据集，从而提高删除操作的性能。
• DialingList表非常大。“拨号列表”表存储上传到“去话活动”的所有联系人。在UCCX版本8.0和8.5中，在将数百万条记录上传到出站活动后，性能问题会导致查询表（这会导致uccxoninit进程上的CPU过高，并导致AppAdmin页面加载缓慢）。 要缓解性能问题，请打开TAC案例，以安装清除DialingList表的Cron作业脚本。在UCCX 9.0版中，为了提高性能，向此表中添加了一个索引，以便从AppAdmin进行更有效的查询。这一变化解决了除了最极端情况之外的所有问题。在UCCX版本10.0中，拨号列表已拆分为两个表，一个用于活动联系人，另一个用于历史联系人，为此问题提供全面的修复。