核心系统某业务超时的问题分析

问题描述:

2012年3月某日日,业务返回“调用失败或用户密码错误” 5579次,其中在11点通知业务部门系统恢复后为4396次,全天共查询号码次数为26553次,其他数据可参考附件

原因分析:

采用自底向上的分析方法

1,  看硬件和日志,通过前面的方法论,硬件无报错,日志无异常;

2,  操作系统资源利用率不超过60%,不存在资源不足的情况;

3,  分析等待事件,从35日起,开始出现大量latch free等待事件,很可能和此时业务超时有关


4,  由于oracle 9i版本的限制,相关statspack报告没有按照时间模型来排序(资源消耗排序),通过只有脚本按照时间排序,定位到可疑sql

5,  对可疑sql(3274434087)分析执行计划和趋势分区,执行计划问题不大,但是执行速度却是越来越慢,并且执行时间慢的时间和故障时间非常吻合


6,  通过业务部分确认,该sql即为空选空写相关业务sql,随着业务量(对应于该sql执行次数)和表中数据量的增加,执行速度越来越慢,当执行时间超过1秒(业务逻辑设计)时即超时,报错“调用失败或用户密码错误”;

优化方案

问题找到了,解决问题的方法也就相对容易了。按照优化的方法论,由于执行执行计划无明显问题,最终根据空选空写业务的业务特点进行如下优化措施

1,  Where条件选择性不足,选出的号码数据过多,需要增加必要的选择条件

2,  不必要的Order by排序操作,消耗大量系统资源,建议取消排序操作

优化效果

经分析,数据库的异常等待时间latch明显减少。

  

主机CPU利用率降低了10%


后续:326日,异常sql再次出现,cpu利用率再次增加,联系业务部分,是业务部署导致,28日重新部署后解决

 


评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值