Exadata磁盘写入性能差,导致数据库出现大量free buffer waits

1、故障概述

某客户的Exadata上,运行着很多套ORACLE数据库,在每个月的征期内,业务系统经常出现卡顿的现象,主要表现为业务数据写入慢,甚至出现业务写入超时的情况。

 

2、故障分析

2.1 AWR分析

(1).分析数据库的AWR报告。(本报告取自于业务高峰期)

从数据库的TOP10等待事件可以看出,当前最为严重的等待事件为:free buffer waits和write complete waits.

free buffer waits等待事件,简单来说,就是ORACLE要进行物理读时,在内存中没有找到合适的空闲内存块,此时就需要唤醒DBWN进程将内存中的脏数据刷回磁盘,然后释放内存,在等待脏数据刷回磁盘的这一过程中,请求空闲内存的进程就进入睡眠状态进行等待,等待事件就为free buffer waits.

write complete waits等待事件,当内存中的一个脏数据块正在被刷回磁盘的过程中,另外一个进程对这个数据块同时发起IO请求,这个IO请求就需要等待,等其被写入磁盘完成后,才能再次访问,这一过程就会产生write complete waits等待事件。

从等待事件大概可以看出,问题在于磁盘的写入性能太差,业务系统的数据变化比较大,导致内存中的脏数据刷回磁盘比较慢。

 

(2).分析后台进程的等待事件。

可以看到,db file parallel write等待事件占用了近80%的数据库时间。平均延迟为11207ms,这也表明,磁盘的写入性能非常非常差。

 

2.2 存储软件日志分析

检查存储软件日志,发现“自动磁盘擦洗和修复”特性已经开启。

“自动磁盘擦洗和修复”特性,主要是为了尽早地发现和解决硬盘的坏道问题,默认每两个星期会自动运行。但是,这个特性带来的负面问题是:磁盘擦洗时,会消耗大量IO,在业务高峰期时,会造成IO耗尽,业务不可使用。

在其他省份,相应的做法是:手动关闭该特性,在每月的征期结束后,手动启动该特性,等磁盘擦洗工作结束,再次关闭该特性。

 

2.3 存储配置检查

检查当前的存储配置,如下所示。

 从存储软件的配置来看,当前FlashCache闪存的配置为WriteThough模式。

WriteThough模式:刷内存中的脏数据时,是直接刷入机械磁盘,才完成刷脏数据操作。

WriteBack模式:刷内存中的脏数据时,是先刷加到闪存卡中,就完成刷脏数据操作,后期再慢慢地将闪存中的数据刷回机械磁盘。

闪存的IOPS远远高于机械磁盘,所以需要开启存储的WriteBack模式,解决写入慢的问题。

 

2.4 GoldenGate配置检查

目前,是从存储节点的机械磁盘所在的磁盘组中划分一部分空间,做成DBFS文件系统,GoldenGate就存放在这个DBFS文件系统中。

由于GoldenGate抽取数据时,会产生大量的IO写操作,并且GoldenGate产生的IO写操作无法使用到存储节点中的闪存资源,这进一步加剧了机械磁盘的压力。

 

3 建议:

3.1 手动控制存储节点的“自动磁盘擦洗和修复”特性.

3.2 调整所有存储节点,开启闪存的WriteBack模式。

3.3 将GoldenGate改成本地的文件系统,减轻存储节点机械磁盘的压力。

 

最终,开启闪存的WriteBack模式后,故障得以解决。

 

posted @   石云华  阅读(18)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· DeepSeek在M芯片Mac上本地化部署
点击右上角即可分享
微信分享提示