机房服务器的处理能不断下降，工程师定位分析故障原因
- 时间：2018-12-24 17:21
- 编辑：admin
- 点击： 次
广州鑫瑞信息，专业是IT运维服务商，15年IT运维技术团队，多名资深的小型机/X86服务器/存储设备/网络设备/数据库工程师，丰富的运维经验，快速，精准的处理各类故障情况。专业的事情让专业的人解决。
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 问题总结
后期将对此日志表只保留当天的数据，历史数据迁移到历史表便于后期的分析用。
