首页 > oracle知识 > oracle存储 >

一个数据库IO性能问题的分析

作者: 初见博客 分类: oracle存储 发布时间: 2021-07-09 11:08

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

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

modb_20210630_a349a8d4-d938-11eb-b723-38f9d3cd240d

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

modb_20210630_a34e690a-d938-11eb-b723-38f9d3cd240d

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

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

modb_20210630_a52d2dec-d938-11eb-b723-38f9d3cd240d

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

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

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

modb_20210630_a5345932-d938-11eb-b723-38f9d3cd240d

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

modb_20210630_a53d8c46-d938-11eb-b723-38f9d3cd240d

modb_20210630_a5466c58-d938-11eb-b723-38f9d3cd240d

可以看出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

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注