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

1 问题现象描述

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

2 问题原因分析

首先通过SQL语句查询交易日志表,按时间(分钟)、交易笔数、平均交易耗时、最大交易耗时、0~0.5秒交易笔数、0.5~1秒交易笔数、1~2秒交易笔数、2~5秒交易笔数、大于5秒交易笔数等维度进行分析,获取处理延时的概要情况进行了解。

然后通过uptime命令检查各服务器负载情况来看,发现数据库服务器的负载呈现明显的增长趋势。

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

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

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

3 问题总结

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181204B07LZU00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励