一次cpu的user比例过高的调优

近期遇一个省的数据库说总是繁忙,idle很小,在凌晨稍微跑几个比较大的统计脚本,idle就出现0的情况,导致业务发生堵塞。

经过连续几天的观察,发现cpu曲线大致如下:

2008年11月18日:

白鳝交流了一下,老白说cpu的user%比例过高可能是由于buffer get比较高的sql引起。可以重点找一下statspack中buffer get比较高的语句。

根据sar出来的结果,查看对应时间段的statspack:

首先查了hash value为1460516408和2446775708的sql,因为这2个sql的执行次数不高,但是单次执行的消耗很高,查询后发现2个sql的consistent gets有47万。与开发沟通后,该sql的执行计划已经无法改变,但是由于是通过时间点触发,可以将该sql的执行时间延迟到6点之后执行。

同时hash value为3767922078之类的sql由于执行太过于频繁,要求该进程的执行频率是否能够降低一些?但是该进程由于涉及状态同步,如果降低频率会引起用户投诉,暂时无法处理该sql。

待调整后,继续观察一天。发现晚上的曲线还是大致相仿:

2008年11月19日:

继续观察对应时间段的statspack:

发现consistent gets很高的那几个sql已经不再出现,但是为何user的比例还是很高呢?

此时,突然发现了执行很频繁的几个sql,cpu time(s)有300多秒!!如hash value 3582277248、3767922078这几个sql的cpu time比昨天调整的consistent gets 还高!!

其实昨天查的时候,也注意过这几个sql,这几个sql虽然是走全表扫描,不过执行的速度很快:

buffer get部分中cpu time这么高,估计是这几个sql影响了。查询了一下该sql在别的省的执行计划,发现是走PK索引的。这个省的主键不知道被谁删除掉了!!

建立PK后,发现user一下子就下去了。

总结:遇到cpu的user高问题,如果没有enqueue,latch free之类的等待,仅仅是cpu time的等待,看statspack 中buffer get中的cpu time(s)高的sql很重要。

相关文章

4条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据