FlashCache write-back因素导致Exadata性能下降

个人简介:石云华,Exadata中国用户组联合创始人,2019年被ORACLE官方授予ACE称号。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,另外一本《Oracle Exadata性能优化》即将面世。

案例概要:

客户有两套核心OLTP类型的数据库运行在传统架构下,底层存储使用的是SSD全闪存,最近购买了一台1/4配置的Exadata X5-2,计划将这两套数据库迁移到Exadata上,数据迁移后发现数据库性能变得异常糟糕。

10月6号Exadata正式上线后,存储节点物理磁盘的IO占用率持续在60%以上,上线后的这几天内,这两套核心数据库经常出现hang的现象,即使没有出现hang的现象,数据库的性能明显感觉也比迁移前慢很多。根据客户反映,目前的业务单量只有500万单左右,双11目标是1500万单,3倍于目前的业务压力,Exadata肯定难以支撑,需要紧急对Exadata进行优化,以应对双11的业务高峰。

案例分析及处理:

分析AWR报告

10号上午来到了客户现场,紧急分析数据库的性能问题。既然是数据库出现了性能问题,那首先需要分析的还是AWR报告。如图10.1所示,是其中一套数据库出现性能问题时间段的AWR报告中的”数据库负载”和”数据库等待事件”信息。


图10.1 AWR报告中的”数据库负载”和”数据库等待事件”信息

从这套数据库AWR报告的TOP 10等待事件可以看出目前存在三大问题:① 事务锁,也即enq: TX – index contention和enq: TX – row lock contention等待事件。② 直接路径写入临时表空间,也即direct path write temp等待事件。③ 检查点未完成导致在线日志文件无法切换,也即log file switch (checkpoint incomplete)等待事件。但前两个问题通常不足以影响整个数据库性能,他们一般只会影响到某个业务模块,而第3个问题则会直接导致整个数据库停止任何响应,表现为整个数据库hang住。

log file switch(checkpoint incomplete)等待事件非常严重,高达14022毫秒,当在线日志组都写完以后,LGWR进程试图重新使用第一个在线日志文件,如果这时数据库仍然没有完成第一个在线日志文件中所对应的脏数据块(例如第一个检查点未完成),该等待事件就会出现。此时在线日志文件状态全部是active状态。该等待事件通常表示你的DBWN写出速度太慢或者存储的IO性能存在问题或者正在执行批量插入导致数据库检查点都无法完全,DBWN进程无法快速地将脏数据块写回数据文件,在线日志文件无法及时切换,导致暂时没有可用的日志文件。

查看数据库alert日志

从数据库alert日志中也可看出,在数据库出现性能问题时,出现大量的cannot allocate new log和Checkpoint not complete等信息,除此之外,没有其他会引起数据库性能的异常信息,这些alert日志信息也表明数据库的日志切换已经出现问题。

查看在线日志状态

正当我还在继续分析数据库的性能问题时,客户反馈当前整个数据库又出现性能问题了,业务全部卡死了,整个数据库hang住。

我的第一反应就是赶紧查看在线日志状态,具体命令如下。

我的天,在线日志文件的状态除了CURRENT之外,竟然全部为ACTIVE,数据库不卡死才怪。ACTIVE表明该重做日志组在数据库崩溃恢复时需要用到,该重做日志组可能已归档或未归档,数据库崩溃恢复时,首先需要根据DBWN检查点确定重做日志位置,读取后面的重做日志文件实现前滚,再根据UNDO实现回滚。

当前数据库的重做日志组全部为ACTIVE,则表明DBWN将脏数据块写回数据文件不及时或存储IO存在问题,DBWR进程写得太慢,导致脏数据块积压在BufferCache中。

紧急处理故障

此刻,为了紧急解决故障,恢复业务,我让客户运维团队临时增加在线日志组,并且每组在线日志文件的大小设置为5GB。

增加完在线日志文件组后,业务恢复,但是业务运行仍然比较慢。这个结果是意料之中的,因为真正的数据库性能问题还没开始解决呢,并且我也不认为当前数据库的性能问题在于日志文件太小或组数太少。

查看IO性能

临时解决完故障并恢复业务之后,我把分析的重点放在了IO性能这一方面,因为这两套数据库是通过DATAGUARD物理迁移过来的,同时所有的数据库参数保持与迁移前完全一致,唯一的区别就是硬件不同,迁移前的底层存储使用的SSD全闪存,迁移后的Exadata底层是机械硬盘加上PCI-E闪存卡,由于这台Exadata是标准化的默认配置,所以PCI-E闪存卡全部配置成了write-through模式的FlashCache,write-through模式的FlashCache只对读IO有帮助,但对写IO没有任何帮助。目前怀疑是这两套OLTP类型数据库的IOPS需求太高,Exadata底层的机械硬盘无法满足IO需求。于是查看所有与IO写有关的性能指标,具体性能指标如图10.2所示。

图10.2 AWR报告中所有与IO写有关的性能指标

从后台进程的等待事件可以看出db file parallel write的平均等待时间为26毫秒,而对于一个正常的系统,该等待时间应该远小于20毫秒。除了db file parallel write指标,其它IO读写的性能指标全部都非常差,比如control file parallel write和log file single write。

查看统计报告

查看整个数据库集群的统计报告。如图10.3所示取自12点至15点的数据库集群的统计报告。


图10.3 数据库集群的统计报告

从数据库集群的统计报告可以看出该数据库db file parallel write等待事件的平均等待时间将近20毫秒,排在等待事件的第1位。这基本上也可以说明IO的写性能非常差。

查看硬盘的IO使用

从EM12C中可以看到Exadata底层的机械硬盘的IO使用情况,如图10.4所示。

图10.4 EM12C中Exadata底层机械硬盘的IO使用情况

当前的机械硬盘IO使用率已经在60%左右,而机械硬盘高峰时刻的平均写入IOPS基本上在300左右,而这个数字差不多是机械硬盘的极限IO。

到了这里,整个性能问题基本上可以解释通了。Exadata上运行的这两套数据库是OLTP类型的数据库对存储的IOPS有极高要求,而Exadata上的PCI-E闪存卡默认配置成write-through模式的FlashCache,这只对数据块的读操作有帮助,但是对数据库写操作没有任何帮助,当数据库SGA中的脏块需要回写时,需要直接写入数据文件中,也即直接写入存储节点的机械硬盘上,而Exadata上每个存储节点上的12块机械硬盘不足以提供如此高的IOPS,导致数据库的DBWN进程刷新脏数据块非常慢,脏数据块刷新延时最终导致所有的重做日志全部为ACTIVE状态,不能被重复使用,此时整个数据库hang住。

案例解决方案:

既然已经定位出性能问题是由于Exadata上的底层机械硬盘的IOPS无法满足写需求,那么就很好解决了,通过前面的知识我们知道开启write-back模式的FlashCache之后,则数据库BufferCache中的脏数据块需要写回数据文件时,会将脏数据块直接写入FlashCache中,后期会慢慢自动地将FlashCache中的脏数据刷回机械硬盘,以提升数据写入性能。

于是,将整个性能故障的来龙去脉告知客户,需要客户尽快能安排时间开启FlashCache的write-back模式,这样,脏数据块写回数据文件时,会先写入FlashCache中,后期再将FlashCache中的脏数据块慢慢地写回数据文件。这种方式能充分地利用PCI-E闪存卡的高IOPS和高IO吞吐量特性,缓解底层机械硬盘的IO压力,提升数据库的写性能。

3天后,客户将FlashCache从write-through模式修改为write-back模式,修改完成后,数据库性能恢复正常,之后毫无压力地支撑了当年的双11活动,修改后的性能指标如图10.5所示。

图10.5 优化后AWR报告中TOP等待事件的性能指标

并不是所有的数据库都需要开启FlashCache的write-back模式,只有数据库写操作成为整个IO瓶颈时,才需要开启FlashCache的write-back模式。所以Exadata默认初始化安装时,FlashCache仍然是writh-through模式,但在新版本的ODEA工具中,在生成配置文件时,FlashCache的模式可以进行选择。

未经允许不得转载:Oracle一体机用户组 » FlashCache write-back因素导致Exadata性能下降

相关推荐