FlashCache资源使用不均导致Exadata性能下降

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

案例概要:

某客户的一套1/4配X5-2 Exadata上运行了两套OLTP类型的数据库,刚上线的一段时间内,两个数据库各方面的性能指标都非常正常,但运行了一段时间之后,发现其中一套数据库的性能比以前差,而另外一套数据库的性能正常。

性能较差的那套数据库,主要表现为cell single block physical read等待事件从刚上线时的1毫秒左右,突然上升至当前的10毫秒左右。这两套数据库都是OLTP类型的数据库,基本上所有的SQL语句全部使用了索引扫描,出现性能变差趋势的这套数据库是客户最核心的数据库,需要尽快帮助客户找到性能变差的原因,并进行相关优化工作,如果性能进一步恶化,则很可能无法支撑当年马上到来的双11活动。

案例分析及处理:

对比分析AWR报告

首先,我还是让客户收集了一下性能正常和性能异常这两个时间段的AWR性能报告,看能否从AWR报告中找出问题原因。性能正常时间段AWR报告,如图1所示。

图1 性能正常时间段AWR报告的性能指标

性能异常时间段AWR报告,如图2所示。

图2性能异常时间段AWR报告的性能指标

以上两份AWR都是取由业务高峰期(每天下午15点至16点),从以上AWR数据对比可以看出:① 性能异常时间段的业务量只有性能正常时间段的一半左右时,但系统的压力反而是正常时间段的一倍左右。② cell single block physical read从性能正常时间段的1毫秒左右,突然上升至性能异常时间段的11毫秒左右。

首先,我们来看看这个cell single block physical read等待事件到底是什么意思,Exadata上的cell single block physical read等待事件,它类似于传统oracle数据库上的db file sequential read,通常出现在索引扫描时,需要访问的数据块不在BufferCache中,而必须从Exadata存储节点的磁盘或FlashCache中读取数据。

如果这个等待事件的延时时间低于2ms,则表明是正常的索引扫描,可以不用太关注,但如果延时时间太高,则有可能是SQL语句太糟糕,访问了大量无效的数据块,也有可能是存储节点上的某方面配置出了问题。

排查SQL语句

最初怀疑是不是TOP SQL语句的执行计划发生了变化,导致访问了大量的无效数据块,从而引发IO变慢?客户很肯定地回答TOP SQL语句的执行计划绝对未发生变化,如果问题出在SQL层面,他们肯定早就自己搞定了,这个客户自己的数据库团队水平是非常高的,大部分的问题都自己解决。听他们这么一说,我也觉得我是把问题想简单了。虽然如此,我自己还是亲自排查了下SQL语句层面,的确,TOP SQL语句没有出现执行计划抖动现象。

收集数据库日志

排除了SQL语句层面的问题后,想看看数据库的alert日志是否有异常信息,很遗憾,在出现性能问题的这段时间内,除了正常的日志切换日志之外,再无其它日志。

其实从AWR报告的TOP 10等待事件也可以看出,整个数据库层面是没有问题的,所以也就不再去收集systemstate或hanganalyze等等信息,对单纯的cell single block physical read变慢,systemstate或hanganalyze等信息基本没什么帮助。

检查硬件信息

既然问题不出在SQL语句和数据库层面,那就需要好好地检查存储节点的磁盘、PCI-E闪存卡是否存在性能低下的问题,如果某块磁盘出现性能问题,则可能会导致整个diskgroup磁盘组出现性能问题。

通过语句检查所有存储节点的物理存储介质是否正常,具体命令如下。

从输出可以看出,当前有两块磁盘存在介质错误,但经过连续多天的观察,这两块磁盘的errorcount未发生变化。只是单纯这些介质错误信息,是不足以断定”磁盘损坏,需要更换的”。通常,对于这种情况的磁盘,ORACLE官方也是不推荐更换的。

继续检查磁盘底层的IO写模式,具体命令如下。

从命令输出可以看出,RAID卡上的所有磁盘是write-back模式,也间接地说明了RAID卡控制器的电池是正常的,如果RAID卡控制器的电池耗光,会导致磁盘写变成write-through模式,从而影响IO写性能。

继续检查FlashCache的状态,具体命令如下。

从命令输出可以看出,FlashCache正常,不存在性能低下的PCI-E闪存卡。

检查存储节点AlertHistory

排查完存储节点的硬件层面没有硬件故障,那就再查查存储节点的软件层面,看是否存在软件层面的报错或告警,有可能会引起IO性能问题,具体命令如下。

没有特别的故障输出,说明存储软件层面没有出现异常。

检查数据库的FlashCache命中率

问题到了这,好像有点近乎于无解了,哪都没出问题,但cell single block physical read等待事件的确是变慢了。我回过头又重新想了想,这是一套单纯的OLTP数据库,基于以前的理论知识,Exadata上的纯OLTP数据库,只有FlashCache特性有帮助,因为它会充分地利用PCI-E闪存卡的IO优势。FlashCache利用越充分,相应的数据库性能也会越好,而Exadata上的智能扫描特性基本上不会使用。

于是,我把重点放在了FlashCache这块,先从FlashCache的命中率着手吧,看看这个数据库的FlashCache命中率目前是个什么情况。从两份AWR性能报告中,获取分析FlashCache命中率的数据。

性能正常时的数据,如图3所示。


图3 性能正常时间段FlashCache命中率性能指标

性能异常时的数据,如图4所示。


图4 性能异常时间段FlashCache命中率性能指标

通过计算,我们可以得出FlashCache的命中率如下。

正常性能时:(17473415 / 17565216) * 100% = 99.5%

异常性能时: (10270760 / 12,343,036 ) * 100% =83.2%

从FlashCache的命中率对比可以看出,cell single block physical read等待事件的平均延时比较差,正是由于性能异常时间段的FlashCache的命中率比较低,这说明这个数据库的FlashCache资源未充分利用。需要访问的索引数据块不在FlashCache缓存中,自然地就需要直接访问存储节点中的机械硬盘,而机械硬盘的IOPS与PCI-E闪存卡是不可同一而语的。底层机械硬盘的IO压力大了,延时也会自然而然地增大。看到了这个对比数据,立马整个人都有点兴奋了,因为离真相也越来越近了。

分析FlashCache内容

下面,需要分析的是FlashCache内容,是什么原因导致FlashCache命中率变得如此之低。

使用我前面章节中提及的FlashCache内容分析工具,我想看看当前性能异常时,FlashCache中到底缓存了些什么东西。通过对FlashCache内容的分析,可以发现:该1/4配的X5-2,一共有9TB左右的FlashCache空间(write-back模式),而性能比较差的这套数据库只缓存了1.5TB的数据块,另外一套数据库却缓存了7.5TB,信息如下。

至此,所有的疑问都得到了解答,数据库A的cell single block physical read等待事件变差,是由于极其宝贵的FlashCache资源被另外一个数据库大量占用,导致数据库A只能去访问性能极差的机械硬盘。同时也可以解释为什么另外一套数据库B没有性能问题,查看数据库B从刚上线和现在的AWR报告,其cell single block physical read基本都在1毫秒以下。

案例解决方案:

与业务人员讨论,这两套数据库都非常重要,那就只能限制FlashCache的使用率,使它们平均分配FlashCache资源,我们可以通过设置IORM,来控制每一个数据库FlashCache资源的使用率,具体命令如下。

以上语句表示开启IORM特性,限制每个数据库至少要保证2730G的FlashCache资源,并将objective设置为auto,允许IORM在确定IO请求优先级时自动确定最佳优化方案。

设置完IORM特性后,检查A数据库的各项指标,如图5所示。


图5 设置完IORM特性后A数据库的各项指标

从以上指标可以看出,系统性能已经大幅提升,cell single block physical read等待事件已经从11毫秒回到了现在的4毫秒,但仍没有回到以前的状态。

再次分析FlashCache的内容,意外发现设置的flashcachemin参数未生效,A数据库使用的FlashCache资源还是1.5TB,而B数据库使用的FlashCache还是7.5TB。这说明当前的性能提升是由IORM特性中的objective=auto实现的。

下面,需要继续分析为什么flashcachemin未生效?搜索MOS资料,可以发现如下BUG:Bug 20323619 IORM FLASHCACHEMIN FLASHCACHELIMIT SETTINGS DID NOT TAKE EFFECT。

ORACLE原厂已经确认这个BUG需要将存储软件升级至12.1.2.2.0以上的版本,再使用flashcachesize参数来限制各个数据库对FlashCache资源的使用,还有一点,flashcachemin和flashcachemax是软限制,在某些情况下,还是能超过这个限制的,但flashcachesize是硬限制。

在这里,我不得不说,在处理这个案例时其实我也犯了一个错误:那就是设置完FlashCache资源限制后,我再次分析FlashCache内容时,两个数据库占用的FlashCache大小仍未明显变化。我当时认为是FlashCache限制中了BUG,导致设置未生效。因为在处理这个案例时,我也有两个知识点在当时不太确定:① 设置完FlashCache资源限制,是否会立刻就能体现出变化?也即B数据库的FlashCache立马从7.5TB下降到4.5TB左右。② 如何来判断FlashCache资源限制生效了?

现在,我可以回答这两个问题了。① 即使设置完FlashCache限制,也不会立刻就能体现出变化来,B数据库超过限制的那部分FlashCache,只会在日后的访问过程中慢慢地释放出来。② 如何来判断FlashCache限制是否生效,可以通过如下语句:

最终,通过限制各个数据库对FlashCache资源的使用,A数据库的cell single block physical read等待事件回到了久违的1毫秒。

未经允许不得转载:Oracle一体机用户组 » FlashCache资源使用不均导致Exadata性能下降

相关推荐