FlashCache管理缺陷导致Exadata性能问题

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

案例概要:

我们的一个客户在1/4配置的Exadata X5-2上运行着两套Oracle数据库,分别为A数据库和B数据库。

运行了一段时间后,其中的A数据库已经从该Exadata X5-2上迁移出去,目前该A数据库已经完全shutdown,但是A数据库所涉及的所有数据文件仍然保留在磁盘组中没有删除。也即X5-2上目前只运行了B数据库。

突然有一天,客户联系我们,反馈当前X5-2上运行的B数据库性能比较差,主要表现在cell single block physical read等待事件经常飙升到十几毫秒左右,同时flashcache的命中率比较低。

案例分析及处理:

  • 在向我们反馈问题的同时,客户也向我们展示了他们在监控平台上收集到的性能信息,cell single block physical read等待事件在每天的性能表现如图10.26所示。


从上图可以看出,cell single block physical read等待事件基本上每天的9点至13点都比较严重。

继续对该等待事件进行细化,查看11点这一个小时之内的更详细信息,如下图所示。


从上图可以看出,cell single block physical read等待事件平均只有36%是小于1毫秒,平均有22%是在4毫秒至8毫秒之间,28%的等待在8毫秒至16毫秒之间。从这可以看出,该数据库的性能的确存在问题。

  • 既然数据库出现性能问题,首先需要提取性能异常时间段的AWR报告。节点1中AWR报告关于数据库负载和数据库等待事件的信息如图10.28所示。

从上面可以看到,cell single block physical read等待事件平均延时到了13毫秒,占用了高达50%的DB time。

继续查看各数据文件的延时情况。如下图所示。


可以看到此时,业务表空间的数据文件延时基本上在20ms左右,说明此时数据库IO性能已经很差了。

  • 检查FlashCache的命中率。

继续分析AWR报告,计算出cell single block physical read等待事件平均延时为13毫秒这个时间段,FlashCache的命中率如何,具体信息如图所示。


FlashCache的命中率=1497957/2105988 * 100%= 71%,才71%的FlashCache命中率,说明FlashCache资源未充分利用。

  • 检查FlashCache的使用情况。

由于Exadata X5-2每个存储节点都配置了5.8TB的PCI-E闪存卡,正常情况下,热点数据都应该缓存在这些基于PCI-E闪存卡的FlashCache中,如果SQL语句需要的数据块未缓存到FlashCache中,则需要读取物理的数据文件,如果大量访问物理的数据文件,则IO性能肯定会大幅下降。

下面,进一步检查存储节点FlashCache的使用情况。

从以上输出可以看出,A数据库还占用了4个多TB的FlashCache,而B数据库仅仅占用了1个多TB的FlashCache资源,这其实就是为什么B数据库cell single block physical read等待事件非常高的原因。

跟客户进一步沟通得知,A数据库已经从Exadata X5-2上迁移出去将近2个月了,目前A数据库处于关闭状态,只是其数据文件仍然保留在ASM磁盘组中未删除。那么新的问题来了,既然A数据库已经处于关闭状态,并且永远也不会开启,那么为什么A数据库还有这么多的数据对象缓存在FlashCache中呢?并且也没有立即释放的迹象。通过这个案例,我立刻联想起以前遇到过的另外一个案例,以前遇到的那个案例大概意思就是已经删除的数据库对象(表或索引)长时间缓存在FlashCache中不释放,官方对此的回复是这些对象会变冷,并最终会被挤出FlashCache。

  • 通过这两个案例,我大胆猜测一下存储节点FlashCache的缓存算法,并指出其中的一些缺陷。具体缓存算法如下:
    1. 当有新的数据对象需要缓存到FlashCache时,先检查存储节点的FlashCache是否还有可用空间?
    2. 如果存储节点的FlashCache已经完全使用,没有发现可用空间时,则检查FlashCache中的哪个数据对象的hitcount最小?
    3. 将FlashCache中hitcount最小的数据对象刷出,并释放空间。
    4. 将新的数据对象需要缓存到FlashCache。


注意:① 这里仅仅涉及存储节点未设置IORMPLAN来限制各个数据库对FlashCache资源的使用量,同时FlashCache资源已经被完全使用,但此刻有新的数据对象需要缓存到FlashCache中的算法。② 该FlashCache的缓存算法纯属个人猜测,这个FlashCache管理算法在互联网上没有任何线索,如果猜测错误请见谅。


以上算法步骤只是非常简单的一个概要算法,相信真实算法远比这复杂的多。从这个推断出的算法中,我们可以发现算法的第2步是存在缺陷的,因为它只是简单地比较FlashCache中的哪个数据对象的hitcount最小,然后把hitcount最小的数据对象刷出FlashCache。其缺陷主要表现为:①、就像以前那个案例中,数据对象已经被删除了好几个星期了,但其数据对象仍然缓存在FlashCache中长时间未释放。如果这些被删除的数据对象的hitcount非常非常大,则这些对象有可能永远缓存在FlashCache中。②、就像这次的案例中,A数据库已经关闭了2个多月,并且永远也不会开启,但A数据库的数据对象仍然大量缓存在FlashCache中。③、这种算法同样会导致在整合环境中,某个热点数据库会占用绝大部分FlashCache资源,而非热点数据库无法占用FlashCache资源的情况。例如前面提及的案例2。

那么如何优化该算法呢?我觉得可以定期检查FlashCache中所涉及的数据库和数据对象的状态,如果发现FlashCache中某个数据库已经长时间未运行,比如一个星期或半个月,则将FlashCache中该数据库的所有对象的hitcount重置为0,同样,如果发现FlashCache中某个对象(objectNumber)在对应的数据库中没有匹配的数据对象,则间接地说明了FlashCache中缓存的对象在数据库层面已经被删除,这类对象同样可以将hitcount重置为0。如此一来,当需要从FlashCache中刷出数据,腾出空间给新的数据对象时,就可以优先刷出那些被删除的对象,或者是数据库已经长期关闭的对象。而不是简单地刷出hitcount最小的数据对象,因为谁也不能保证hitcount最小的数据对象在日后不会被再次访问。以上算法优化只是个人见解,有点扯远了。

下面,继续这个案例的处理,既然已经知道是FlashCache资源使用异常,导致B数据库cell single block physical read等待事件非常高,那我们可以有两种方法来解决这个问题。

方法一:针对B数据库,设置IORMPLAN,将FlashCache资源的使用设置到最大,也即将整个FlashCache资源全部给B数据库。具体设置如下:

方法二:手动flush整个FlashCache,然后重启该存储节点的CELLSRV服务。依次在所有存储节点上执行。

由于担心方法二会对数据库IO有冲击,所以建议使用方法一来提升数据库B的FlashCache使用量,同时将A数据库的对象刷出FlashCache。

客户使用方法一设置了IORMPLAN,限制了B数据库基本上使用所有的FlashCache资源。但一个星期后,客户告诉我,设置了IORMPLAN后,B数据库的性能改善不明显,我再次远程登录到他们的环境中,查看FlashCache资源的使用情况,发现B数据库的FlashCache资源使用有所增加,A数据库有所减少,但A数据库缓存在FlashCache的数据块仍然没有完全被刷出。

最终,只能建议客户使用方法二,手动flush整个FlashCache,然后重启该存储节点的CELLSRV服务。依次在所有存储节点上执行。

案例延伸:

在这个案例中,问题其实非常明显了,A数据库已经关闭,并且永久停止使用,但FlashCache中缓存了大量A数据库相关的数据,并且长时间都未被刷出。这应该算是FlashCache资源管理算法中的一个缺陷,像该案例这种极端情况,A数据库缓存在FlashCache中的数据最终肯定会被刷出,这点毫无疑问,但问题是需要的时间太长了。

如果我们有一种手段,可以根据数据库名和对象的ID就能将具体某个数据对象从FlashCache中刷出,那就能非常容易地处理这个案例,而不是需要将整个FlashCache全部刷出。

未经允许不得转载:Oracle一体机用户组 » FlashCache管理缺陷导致Exadata性能问题

相关推荐