日常巡检数据库服务器时发现了一台服务器从昨晚开始到目前CPU使用率高达95%以上,马上登录上去看了下导出了一份AWR报告发现了几个问题与大家分享一下。
导出AWR报告之后肯定先看DB time,因为是CPU 8个核心所以DB time 477分钟算非常高了,基本上CPU都在95%以上。
接着看了下profile
发现逻辑读、物理读还有IOPS这块都非常高,每秒22G的逻辑读1.8G的物理读将近15W的IOPS,用iostata查了下,幸好存储性能非常好才占用了30%左右(因为存储这块不归我管,我也不知道存储是不是用了SSD)。
发现这些问题之后我心里就有底了,大概率是SQL问题,接着马上看了下后台等待事件
果然不出所料,单快读、多快读等待事件是排在最上面顺带还有什么直接路径读和read by other session,单快读和多快读等待事件很常见这个就不用说了直接去检查SQL或者增加相应的索引。我查了下read by other session发现是会话抢读造成,同时伴随单快读、多快读等待事件,所以直接找到这几个会话的SQL优化
接着就开始定位具体的SQL,继续往下看
第一条SQL是查询语句执行次数是0意味着执行了一个多小时还没执行完,这条语句肯定要抓出来看看对应的执行执行计划,后面的几条update肯定也是有问题的
然后又看了下使用IO较多的SQL,果然还是那几条。。然后点开这几条SQL发现都是在update TB_FOC_I_FLIGHT_INFO、TB_FLIGHT_DYNAMIC等几张表
其中很多SQL都是表嵌套的方式来关联更新,1个小时更细了3W次所以性能瓶颈很大。
看到这里这次的性能问题就解决了,剩下的就是反馈给开发给开发叫他们整改实在改不了我在出手,但是这个库我仔细看了还有几个小问题。
内存设置太小,服务器有32G上面只部署了一个数据库居然连30%的内存都没给到,直接给个80%都没问题,把buffer cache增大了在说!
还有这个审计表居然是段等待最高的,说明数据库强制审计了很多对象到该表,如果用不到审计其实关闭。
ITL事务槽等待,这个对象需要重点关注。