备库CPU使用异常优化（r6笔记第73天)

最新推荐文章于 2024-03-22 17:08:00 发布

jeanron100

最新推荐文章于 2024-03-22 17:08:00 发布

阅读量248

点赞数

本文链接：https://blog.csdn.net/yangjianrong1985/article/details/102507187

版权

一般在一些容灾环境中，尤其是在11g的ADG非常普及的场景下，备库被赋予了更多的责任，很多时候在容忍一些延迟的情况下，有些应用的大量数据查询任务直接放到了备库，把它当做一个只读节点来使用，所以在有些情况下，可能备库的压力还是蛮大的。最近自从把备库纳入zabbix的监控体系之后，有一个备库总是在午夜发来一条报警邮件。内容大体如下：adb0_s1@10.127.xx.xx_报警------------------------------------报警内容: CPU utilization is too high------------------------------------报警级别: PROBLEM------------------------------------监控项目: CPU idle time：53.8 % ------------------------------------ 报警时间:2015.09.29-01:50:27单纯从报警信息来看，这是一个备库中发出的报警，所以很自然联想到是有大量的批量查询任务在运行。每次看到都直接忽略，看着最近的报警信息处理，多多少少都能发现点什么，就决定好好挖掘一下，看看有什么能改进的，目标就是不改动报警阀值，能够把负载控制在合理范围之内。根据报警的时间点来抓取ash报告，前后浮动几分钟，这次没有连错就是备库，但是没有发现任何的信息，连top event都没有。查看crontab，也没有发现任何相关的任务在运行。自己都有点怀疑是不是CPU使用瞬间抖动造成的，是否为误报。貌似数据库层面没有很明显的发现，至少通过前后的几分钟时间来看，没有发现任何active session信息。我们来看看系统级的CPU使用情况，是否存在着明显的CPU过载现象。 0?wx_fmt=png 蓝色部分是CPU使用的比例，在每天的凌晨到晚上6点都在满负荷运行，然后会有一些短暂的空闲期。每天都是如此。所以CPU的过载问题是很明显而且有规律的。第二天早上查看的时候，发现这个时间段还是在问题时间段之内，使用sar命令也确实能够看到CPU的使用率情况（最后一列）01:20:01 AM 99.4801:30:01 AM 93.7001:40:01 AM 66.5401:50:01 AM 47.2902:00:01 AM 41.4602:10:01 AM 38.3002:20:01 AM 27.3502:30:01 AM all 70.61 0.00 1.84 0.04 0.00 27.51这个时候还是使用top命令来看，能够抓取到目前正在占用大量CPU资源的几个进程都是oracle用户进程。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1113 oracle 19 0 16.0g 9.1g 9.1g R 96.3 29.0 299:56.69 oracleadb0 (LOCAL=NO) 980 oracle 17 0 16.0g 9.1g 9.1g S 91.6 29.0 303:02.33 oracleadb0 (LOCAL=NO) 599 oracle 16 0 16.0g 9.2g 9.2g S 89.0 29.2 321:21.08 oracleadb0 (LOCAL=NO) 1313 oracle 16 0 16.0g 9.1g 9.1g R 88.0 29.0 290:09.17 oracleadb0 (LOCAL=NO) 982 oracle 15 0 16.0g 9.1g 9.1g R 86.7 29.0 302:18.63 oracleadb0 (LOCAL=NO) 884 oracle 17 0 16.0g 9.1g 9.1g R 85.7 29.0 308:39.81 oracleadb0 (LOCAL=NO) 拿出第一个进程分析，看看这个进程在干嘛。