是什么引起数据库响应超时？

一、问题背景

一个核心业务数据库部署在AWS的EC2实例上，在业务活动期间发生了性能抖动导致业务超时。

下面记录一下问题排查的流程。

二、问题分析

1. 监控指标分析

发生问题后，第一时间肯定要看监控！首先分析服务器基础监控。

服务器的Load1使用率不足40%，看上去未达到瓶颈。

发现问题发生期间，数据盘的IOPS有不规律的波动，但是整体上IOPS峰值未超过1500，看上去不像达到了瓶颈。

再观察一下MySQL服务指标，可以看到问题发生时数据库运行线程是有突增的，同时也观察到数据库insert和update同样有突增。

这一点与调用方确认当时确实是有大量的写入和更新，但是从服务指标上看并没有达到服务运行的瓶颈。

2. 漫长的排查流程

重新梳理一下各方的情况。

基础监控

我们又重新Review了服务器监控指标，确认当时服务器的CPU使用率、内存使用率、磁盘使用率和磁盘IOPS均没有达到上限，基础资源部分看起来正常。

MySQL服务

MySQL层面没有慢查询日志，说明MySQL本身的处理逻辑正常，业务也并没有新增不合理的SQL。只是发现当时MySQL的threads_running有上涨，说明当时排队的请求很多，具体为啥就不知道了。

业务调用方

业务当时没有上线或其它变更。从调用量上来看，是有突增的，这也与MySQL的监控指标吻合。

但是业务本身的资源使用率正常，处理其它逻辑的耗时也正常，只是对MySQL请求慢了，因此不像是业务本身的问题导致。

看了一圈只是看出当时MySQL慢了，但是为啥慢了还是不清楚，问题究竟出在哪里？

3. 被忽略的指标

想来想去，影响MySQL最重要的还是两类资源：CPU和磁盘IO。

CPU使用率从监控上看基本没有大的波动，但是磁盘IO确实是有明显波动的，只是没有达到IOPS的阈值。所以磁盘IO还是重点怀疑对象。

从监控大盘上看IOPS峰值不超过1500，看似未达到瓶颈，但监控采点间隔是1分钟，会不会有瞬时突增达到了上限但是监控没有采集到（实际该磁盘IOPS配置上限为6000）？

关于这点我们咨询了AWS后台工程师，AWS的EBS存在一个我们之前忽略的监控指标：VolumeIdleTime。官方对这个指标的描述如下：

VolumeIdleTime – The amount of time when no read or write operations were waiting to be completed during the period.意思是EBS实例在监控周期内没有读写操作的时间。

那么我们查看一下发生问题的EBS实例这个指标的情况：

结果令人吃惊，该实例每分钟的空闲时间超过50s，按这个计算，实际峰值的IOPS可能是监控指标的6倍！1500 * 6 = 9000，很显然已经超出了EBS配置的IOPS限额6000！

我们可以在CloudWatch上配置一个自定义指标：(每分钟读IO次数+每分钟写IO次数)/(1分钟-VolumeIdleTime)，来更直观的观察EBS实例实际IOPS的波动情况。

通过下图可以看到，确实有很多突增的点IOPS峰值超过了6000，这是导致MySQL访问超时的直接原因。

至此，问题根因得到了确认。

三、总结

我们最后总结一下问题原因：

业务写入突增导致MySQL服务对应的底层EBS实例IOPS飙升，短时间超出限额6000导致性能受限，引起业务超时；
EBS实际的IOPS可以通过VolumeIdleTime指标做更精确的计算。

四、后续优化方向

1. 如何快速查看EBS实例真实的IOPS

这个指标由3个CloudWatch原始指标聚合而成，配置较为繁琐。

我们可以提前保存一个CloudWatch源指标模板：

{"metrics": [[ { "expression": "(m1+m2)/(PERIOD(m1)-m3)", "label": "Actual IOPS", "id": "e1" } ],[ "AWS/EBS", "VolumeReadOps", "VolumeId", "your_volume_id", { "id": "m1", "visible": false } ],[ ".", "VolumeWriteOps", ".", ".", { "id": "m2", "visible": false } ],[ ".", "VolumeIdleTime", ".", ".", { "id": "m3", "visible": false } ]],"view": "timeSeries","stacked": false,"region": "ap-southeast-1","stat": "Average","period": 60
}

需要查看时只需要替换一下VolumeId和region即可查看对应EBS实例的自定义Actual IOPS 指标。

2. 增加秒级监控

排查问题时，我们永远都希望监控的粒度越细越好，但是更频繁的指标采集动作可能会导致服务器本身的压力上升。因此在增加秒级监控指标时需要谨慎的评估这一点。

我们可以只选择最关注的核心指标，将少量的指标增加秒级监控，这样在尽量不增加服务器压力的同时达到细粒度指标采集的目的。

3. 推动业务优化

由于EBS的性能普遍比机房物理机上的SSD性能要差，业务需要更严格的判断突增请求的合理性，是否能通过消息队列进行削峰填谷，使请求更加平稳。

同时为缓解业务异常，可以使用GP3类型EBS实例，把IOPS配额临时调大，等业务优化后再将IOPS配额恢复。