guoxilin
作者guoxilin2018-11-30 11:39
高级非功能测试专家, 某科技公司

生产问题-某接口服务处理能力急剧下降问题原因定位分析

字数 696阅读 903评论 1赞 6

1 问题现象描述

项目上线的第二天,发现在早上10点后,随着时间的推移,运维反馈耗时一直在增长,且延迟增加的交易总笔数呈现明显的增长趋势。而前一天平均处理时间不到1秒,而那时交易的处理延时很多都开始超过2秒,且呈现增长趋势。
2qw68gx5w4s

2qw68gx5w4s

2 问题原因分析
首先通过SQL语句查询交易日志表,按时间(分钟)、交易笔数、平均交易耗时、最大交易耗时、0~0.5秒交易笔数、0.5~1秒交易笔数、1~2秒交易笔数、2~5秒交易笔数、大于5秒交易笔数等维度进行分析,获取处理延时的概要情况进行了解。
然后通过uptime命令检查各服务器负载情况来看,发现数据库服务器的负载呈现明显的增长趋势。
wy5t58jzt4b

wy5t58jzt4b

进一步获取数据库awr快照,从慢查询、非空闲等待事件、cpu、IO等消耗情况进行分析,主要发现某个SQL的cpu资源使用占比太高,
stlywkxrfoq

stlywkxrfoq

此SQL语句访问到的表是一张日志表,已有90多G,且查询条件对应的列A没有索引。因此怀疑问题发生的原因为此表部署时只是重命名后没加索引,通过生产环境和压测环境数据库索引约束对比。发现压测环境此日志表列A建了唯一性约束(注:创建唯一约束会在Oracle中创建一个Constraint,同时也会创建一个该约束对应的唯一索引),而生产环境日志表列A没有约束也没建索引。导致当此日志表数据量超过一定量时访问性能急剧下降。
7ebdk9p13el

7ebdk9p13el

对列A建唯一性约束后,数据库的负载降为正常,系统处理能力,处理能力恢复正常。
zgeq0n5g7d

zgeq0n5g7d

3 问题总结
后期将对此日志表只保留当天的数据,历史数据迁移到历史表便于后期的分析用

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论1 条评论

#prankvc项目经理, 据说单位名字不能为空
2018-11-30 17:30
思路很好,顶起!
Ctrl+Enter 发表