健康分析与问题溯源

这个系统是经常出问题的，在一年前就出过几次问题，甚至导致了2次数据库宕机。当时我们通过AWR报告分析是写IO性能存在问题，IO延时过高，导致了OS层面的异常，最终导致宕机。但是存储厂商出具的报告里，存储一切 正常。于是乎，就找了开发商垫背，找到一堆不优化的SQL，让开发商去整改了。确实也是，绝大多数的系统找出几十上百条有问题的SQL不是个难事。开发商也推脱不掉，不断的优化SQL，不过这个系统该出问题还是出问题。客户也认为软件质量太差导致系统三天两头出问题。

这回比较严重，正好是业务高峰期，业务部门压力很大，系统经常出现缓慢现象，甚至出现了宕机。业务部门投诉到领导办公会，IT运维部门的压力就大了。幸好这回客户已经上了健康分析工具。于是通过健康分析我们很容易就能看到问题在哪：

从这里可以看到很明显的IO问题。通过AWR报告，也可以看出类似的问题：

log file sync相当的高，写IO的延时也很不正常。于是客户把存储厂商由叫过来做了分析。和上回一样，存储厂商仍然拿出一份洋洋洒洒的分析报告来，最后的结论还是存储没问题。和这个能用太阳黑子爆炸来解释SAN网络丢包问题的高手打交道，没点真本事还真的不行，于是我们只能正面应战了。和上回不同的是，这回我们的工具比以前只有awr报告要强多了，IT健康分析工具很快就找到了IO问题的规律性的曲线：

可以看出，周期性的存在IO延时较高的现象，其中一个点是白天业务最高峰的时候，一个点是系统备份的高峰期。都是存储IO负载较高的时候。而除了这两个点之外，存储的整体性能是不错的。所以存储厂商总是拿一些平均值来证明系统不存在问题。找到规律后，后面的事情就容易了。对这个存储上的所有数据库系统的log file parallel write指标做一个统计分析，就很容易发现问题了：

从分析结果可以看出，绝大多数系统在本系统存在日志写IO延时过高的时候，IO写的指标都不正常，只是因为其他系统业务量不大，所以没有反映出比较严重的问题而已。从这一点上，可以驳斥存储厂商“如果存储有问题，为什么这个存储上50多套系统，只有这套有问题？”的提问。至此大家可能觉得应该尘埃落定了，不过问题还没那么简单，存储厂商依然坚持他们的指标没问题。我们看到的延时高是存储IO负载较大的正常表现。指望存储厂商帮助查找原因是没啥指望了。于是我们只能继续分析。在对多路径性能进行分析的时候，我们有了重大发现：

针对存在问题的系统在问题时间点的同一块磁盘的多条路径进行分析，发现其中一条路径的写IO延时比其他路径高出30%，另外有一条路径IO延时也偏高。这时候存储厂商只能认可我们的发现，乖乖的配合故障定位了。后经检查发现写IO偏高的两条链路的SAN网络丢包率高于其他链路，更换SAN交换机端口后，高峰期写IO延时虽然仍然达到40毫秒左右，不过很少出现超过50毫秒的现象，数据库系统HANG死现象也基本消失。最后我们总结下这个案例，这个案例最终能够解决的根本原因是因为健康分析系统的建设，使数据采集更为全面，并且工具支撑更为丰富。问题出现后我们通过健康管理工具提供的分析图表和数据，结合专家的分析，最终定位了问题，解决了这个历时一年多的问题。

通过这个案例，我们的健康管理工作也积累了一条新的运维经验。以前在后端存储性能监控方面，只关注OS IO的平均延时与吞吐量，并没有关注多条路径的IO性能差异；通过多条路径的读写IO性能差异，可以发现后端存储可能存在的隐患；通过对某个IO负载具有代表性的磁盘的多条路径的IO延时与吞吐量之间方差与平均值、最大值进行监控可以有效发现类似问题。在健康管理工具中增加这方面的运维经验，就可以有效的在下次类似问题发生时能够及时发现，并通过工具实现问题定位。