EN 联系我们加入我们
典型案例
您现在的位置:首页 > 典型案例
【案例分享】业务平台基本库CPU使用率高问题分析


客户应用生产系统是使用两节点Oracle RAC数据库环境,6月19日应用运维人员对其进行数据清理和导数操作后,两个数据库节点的CPU使用率频繁达到90%以上,并持续了近10天,严重影响后续任务的执行。

工程师29日到达现场进行分析排查后,定位了此次性能问题的原因并提出解决方案,实施应对方案后,两个数据库节点的CPU使用率下降到正常标准,得到客户肯定。


一、故障处理


1、基本信息收集



l  数据库环境:Oracle 11.2.0.3 RAC

l  操作系统:ASianux Server 3.4

l  近期CPU趋势:


image001.png

image003.png



分析CPU趋势发现:22日之前,1节点CPU使用率峰值偶尔会达到90%以上,22日之后,达到90%以上的频率明显升高;2节点峰值稍高于1节点,趋势类似。

与客户沟通了解到:19日之前,两个数据库节点的CPU使用率已经偏高,偶尔会达到90%以上;但22日之后频率明显升高,CPU的内核态消耗偏高,处于20%-25%左右。


2、初步分析

工程师在收集分析了AWR和ASH等报告以及等待事件后,发现如下问题:

image005.png


l  分析等待事件发现,等待次数较多的是单块读,往往是由于使用了错误的索引。

l  log file sync 和 gc 相关的等待说明两个节点存在相同业务,并且节点间数据传输频繁。

l  direct path read 等待事件往往意味着出现了并行SQL,或是因为执行计划改变导致SQL使用了错误的访问路径。

l  shared_pool和buffer cache存在抖动现象。


3、深入分析

3.1 工程师首先根据SQL执行情况,对执行耗时和CPU消耗最多的语句进行分析。


image007.png


image009.png


image011.png

可以看出语句7u4g4ab1vkw5a 耗时、消耗CPU以及逻辑读均较多。

应用运维人员在19日对数据库做了rename表和重建索引的操作,语句 7u4g4ab1vkw5a 涉及的表 vnod_info_91 无统计信息。

此表有两个索引,根据谓词可以看出,此查询应使用唯一索引,但由于缺少统计信息,优化器错误的选择了另一个索引进行范围扫描。此语句执行次数较多,引起异常等待,并且占用CPU较高、仅有一个错误的执行计划,buffer cache和shared_pool的内存转换有可能受此语句影响。


image013.png

image015.png

显然应该使用唯一索引,但选择了IDX2。


3.2 数据库监控用户执行了一些并行度较高的查询。

工程师在29日上午10:04和11:22出现的CPU报警分析中,直接定位到此用户的并行查询。一个查询开启32个并发,另一查询开启8个并发,等待事件为direct path read。

image019.png


3.3 其他并行查询

值得注意的是,白天业务时段内,其他应用用户也存在并行查询,虽然并行度不高,但语句较多。

image021.pngimage023.pngimage025.png


3.4 工程师对数据库表和索引做了检查,发现数据库本身也存在大量带有并行度的索引和表。

3.5 数据库备份的时间为每天0点开始,共持续17个小时左右,运行备份程序的节点CPU需要多消耗15%左右。

3.6 两个节点运行相同业务,且没有关闭DRM,数据在节点间传输过于频繁,可能引起log file sync等待,对内存的分配又会导致系统态消耗CPU。

3.7 这套数据库禁用了每天收集统计信息的任务,并且未开启自主定期收集。


二、处理建议



l  对表vnod_info_91进行统计信息收集,确定是否执行计划改变为唯一索引扫描。

l  建议应用运维人员编写对业务表的统计分析脚本,排除特别大的表,避免优化器选择错误的执行计划。

l  将存在并行度的表和索引重置并行度为1,清理无用的索引。

l  尽量减少其他SQL的并行查询,确定是否可以使用索引进行优化。

l  监控用户在非业务繁忙时段执行并行度较大的查询。

l  RMAN备份时间调整为2天或3天一次,减少对资源的占用,避免业务繁忙期间频繁备份。

l  在业务允许的时间窗口关闭DRM。

l  在压力和负载允许的情况下,相同类型的业务尽量使用单独的RAC节点,避免产生过多的gc等待。


三、经验总结


l  通过本次事件可以发现,这套数据库存在较多问题,CPU使用率的持续增高并非突发事件,而是反映出一段时间以来数据库的运行情况。

l  数据库在此次性能问题出现前,已开启了较多并行查询,CPU使用率一直平均在50%左右,问题并未暴露出来。进入6月后,随着新业务不断增加,日常操作增多,导致CPU使用率较之前已有所增加;19日又新增了业务,表面上看是使用了错误的索引导致CPU使用率持续增加,实际上是多个问题的一次综合爆发。

l  由于停机窗口以及业务需要等问题,本次并未实施全部建议。目前每天运行收集统计信息的脚本,删除无用索引,重置表和索引的并行度为1;语句7u4g4ab1vkw5a使用唯一索引,两个数据库节点的资源使用情况亦得到较大改善。通过CPU趋势图可以看出,29日晚至30日凌晨开始收集统计信息后,两个节点CPU使用率呈下降趋势。至7月3日,CPU使用率趋于稳定。如果后续将其他操作建议落实,CPU使用率将进一步下降。


如欲了解更多,请登录安图特官方网站:www.antute.com.cn

版权所有 安图特(北京)科技有限公司 备案号:京ICP备17074963号-1
技术支持:创世网络