今天讲的是一个数据库优化的问题。实际上，数据库系统就像河流一样，不是静态的，而是一个动态变化的体系。从上游的应用服务器到下游的SAN网络，存储系统，任何地方存在礁石，都会形成不流畅的水流，就会影响整个体系的总的吞吐量。下面我们来看这个案例。

一个用户每天晚上11点开始跑批处理，以前系统一直很正常，不过最近这段时间批处理的运行时间比平时高了好几倍。他们自己也分析了一下，执行计划没有出现变化。说实在的日统计的业务，一般也都是扫描全表，执行计划也不会出现太大的变化。从AWR报告上，我们明显可以看出系统的IO存在性能问题。

可以看出系统中存在不少多块读，这是因为当时主要负载是批处理操作，主要是对数据进行各种各样的统计分析。从延时上看，这个指标似乎也不是很差，15毫秒的平均延时应该还是可以接受的。

不过如果我们对比一下这套系统在第二天白天业务高峰期的IO情况，就可以知道15毫秒的延时比平时已经是高了很多了，因为这套系统的核心数据都存储在SSD盘上。

我们再来看看IO统计，在晚上批处理期间，IO负载其实也不是很高，平均每秒50M的读和6M多的写，IOPS加载一起也不到500。在这种负载下，SSD盘出现这样的IO延时是不可接受的。

从AWR报告的角度上来看，基本上我们可以认为是IO性能出现问题了。不过存储运维部门认为这是不可能的事情，从存储角度的监控一切都是正常的，存储上相关的磁盘组的性能很好，都是低于1毫秒的，存储的负载也不是很高，不大可能出现存储方面的性能问题。

这种跨部门的协调是十分麻烦的，在这种情况下，我们必须有更丰富的证据，才能让存储部门进行更为深入的分析。于是我们就必须对OS的IO性能进行分析，从而获得能够让存储部门深入分析的证据。

幸运的是，客户的OSW一直在运行，分析一下OSW的数据有助于我们获得更有价值的证据，以便于和存储运维团队进一步交流。OSW中有iostat的数据，不过从那么多的数据里去找异常是十分麻烦的事情。在这里我们有一个分析小技巧，首先去分析vmstat的数据，从vmstat的b队列或者p队列（IBM AIX使用裸设备的情况）去判断某个时间点出现过IO性能问题。这个案例用户正好是使用了AIX的裸设备，于是我们查找p队列比较高的时间点。

可以看出23：14：56的采样点发现了P队列很高的情况。于是我们就可以搜索IOSTAT中的这个时间点的数据。

可以看出HDISK19/20的最小服务时间和平均服务时间都很正常，不过maxserv都十分高。而这些盘的queue都很小。除了这两块盘，不少IO负载稍微大点的盘都存在类似的问题。从这个数据上，我们有理由怀疑是后端存储出了问题。于是我们把这些证据提交给了存储运维组。不过他们再次查看了存储的监控系统，甚至在晚上数据库存在IO性能问题的时候开启了存储实时监控，也没有发现什么问题，从存储上看到的各种负载与IO延时都是十分正常的。

靠自己的运维人员是无法定位故障原因了，于是通报了存储厂商。厂商对这个问题十分重视，派了5/6个专家过来对存储又是一通检查。最终的结论依然是存储没有任何问题。于是他们再次和我联系，讨论这个问题。我当时就问他们，你们对整个后端都做了检查了吗？存储和整个SAN网络。因为从数据库服务器的角度，我们认为IO肯定存在问题，而且问题出现在OS之后的那些环节，不仅仅是存储本身。

于是存储厂家再次进行排查，根据我的建议，他们首先检查了SAN网络的相关端口是否存在丢包问题，也没有发现任何异常。然后再对整个SAN网络上的每台SAN交换机进行了检查。经过几天分析，终于有结论了，原来是核心SAN交换机的背板带宽满了，导致背板交换出现了严重堵塞，影响了IO性能。

SAN交换机背板带宽问题影响IO的问题，我上一次遇到已经是8年前了。随着SAN交换机这些年的快速发展，这个问题已经多年没出现了。而这个客户的存储系统与SAN网络是2017年升级的，2019年后为了提高数据库的性能，很多存储系统上都添加了一些SSD盘，核心业务系统大多数都迁移到了SSD盘上。SSD盘的使用，让业务高峰期的存储IO流量比平时高了十倍以上。每天晚上11点开始到第二天的2点多，大量的批处理业务、数据库备份等作业集中运行。以往都是HDD的时候，SAN交换机背板是肯定用不满的，而大量更换SSD盘后，高峰IO流量已经大大超出核心交换机背板的带宽了。

找到问题原因后，解决起来就比较简单了。首先先把一些备份作业的时间做一下调整，推后2个小时执行，让核心批处理业务能够正常完成。另外就要马上启动SAN网络的扩容改造工作，扩充核心SAN交换机，彻底消除这个瓶颈。备份策略调整后，核心系统的批处理性能恢复了正常。

这个优化案例提醒了我们系统优化一个应该注意的问题，有时候数据库的问题解决之道在数据库之外。随着SSD的大规模使用，SAN网络的核心交换机背板带宽问题又开始出现了，我们在优化存储的IO的时候，不能光考虑使用SSD盘替代HDD，还要注意我们的SAN网络是不是能撑得住。

来源：https://www.modb.pro/db/77745