本文翻译自Guy Harrison的blog: More on the database flash cache, 这是他写的关于Flash Cache系列文章的第二篇, 后面还有一篇对比测试Flash Database与Flash Cache的文章, 我也将翻译出来放到此处, 另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.

原文地址: 数据库Flash Cache(II)

数据库Flash Cache(II)

我非常期待我的高性能Flash SSD(一个Intel X-25E),但同时,我已经在一套便宜的硬件设备上(我的前一篇文章中对此做了说明)做了很多数据库Flash Cache的测试. 有时,在较差的硬件上测试新特性也非常有用,因为你可以观察到一些在高速运行的环境下不会发生的现象.
最初,我天真地认为数据块会被Oracle的服务进程拷贝到Flash Cache中.比如,当我从磁盘读取的时候,同时将数据块放到Buffer Cache与Flash Cache中.然而,通过观察,实际情形可能是, 当数据块将要被刷出Buffer Cache的时候, 由DBWR进程将此数据块从Buffer Cache移入到Flash Cache中.
当然,这是一种更好的处理方式.DBWR可以异步的将数据块写入Flash Cache中,从而用户会话可以获得好处,在数据块写入Flash Cache中的时候不需要进行等待(比从磁盘读取耗费更少的时间).
因此,一个数据块可能有一个如下图的生命周期:

• Oracle服务进程从磁盘读取文件的一个数据块,并将其放到Buffer Cache中
• 如果一个会话在稍后需要访问这个数据块,并且这个数据块仍然在Buffer Cache中,就可以直接从Buffer Cache中读取这个数据块
• 在这个数据块离开Buffer Cache之前,DBWR将它写入Flash Cache(如果DBWR不是太忙的话)
• 如果一个会话稍后需要访问这个数据块,并且它还在Flash Cache中的话,就可以从Flash Cache中读取这个数据块(有可能会将这个数据块放回到Buffer Cache中)
• 如果这个数据块被修改了,DBWR进程最终会将这个数据块写回磁盘.(问题:Flash Cache中那些没有被修改过的数据块会发生什么呢?)

DBWR 与 Flash Cache

从闪存上读取的速度是非常快的,但是往闪存上写就要慢很多了.因此,为了避免性能问题,DBWR进程应该:

• 1. 不要去写闪存, 除非不得不写,并且
• 2. 如果有其他更重要的活动的话,一点都不要写闪存.

对于第一点,在数据块将要被刷出Buffer Cache之前,DBWR进程不要填充Flash Cache.也就是说,DBWR不会为了防止数据块将要被刷出Buffer Cache去写这个数据块,而只是这个数据块确实(或许是可能性很高的时候)将要被刷出Buffer Cache的时候才会将其写入Flash Cache.在数据块被写入Buffer Cache的时候,我们没有发现对Flash Cache的写操作, 同时有其他数据块被刷出Buffer Cache的情况除外.
第二点,当DBWR忙于将脏块写入到磁盘的时候,不会去写Flash Cache,也不会推迟将要被刷出Buffer Cache的数据块的刷出时间.DBWR进程必须尽可能块地清除Buffer Cache中的脏块,否则”free buffer waits”等待事件就会阻止新的数据块被读入Buffer Cache中.如果数据块将要被刷出Buffer Cache,而同时DBWR进程又很忙,这些数据块将不会被写入Flash Cache,统计信息项’flash cache insert skip: DBWR overloaded’将出现增长.

度量DB Flash Cache的效率

下面的查询报告了DBWR由于太忙或其他原因而跳过写Flash Cache的次数:

• 我认为我理解”DBWR overloaded”统计项的意思,DBWR忙于写脏块到磁盘而没有足够的处理能力来将干净的数据块写入Flash Cache.
• “flash cache insert skip: exists”统计项也比较容易理解.如果我们从Flash Cache将一个数据块读回Buffer Cache,它还会继续保留在Flash Cache中.当它再次在Buffer Cache中被刷出的时候就不再需要写入Flash Cache了.
• “not current”统计项可能表示,DBWR明白磁盘或者Buffer Cache中还有这个数据块的一个更新的拷贝,因此拒绝写一个版本到Flash Cache上.
• “not useful”统计项,我无法理解…

我认为这里最大的启示是:
在一个DBWR非常繁忙的系统上,DB Flash Cache可能会非常无效率.
要测量出使用Flash Cache带来的好处,我们可以计算由于使用Flash Cache而被避免掉的物理读的次数,以及乘上每种读操作耗费的平均时间.下面这个查询尝试做这个对比,虽然仅仅针对单块读操作:

结论

DB Flash Cache的架构使得我们可以对与闪存SSD相关的相对糟糕的写性能可以显得稍微放松一点.如果我们将数据文件放到闪存SSD上,我们可能会有遭遇”free buffer waits”瓶颈的风险: DBWR可能会由于尝试往低速(从写延迟的角度上看的话)的闪存盘上写数据块而中止,相对于磁盘来讲,我们可能实际上遭遇了更糟糕的性能,至少对于有非常高的写频率的应用来讲.相应地,几乎不应该出现实际的负面因素,可能出现的更糟糕的情况是,DBWR太忙,以致于不会去填充Flash Cache,而使得Flash Cache变得更加无效.
DB Flash Cache的效率依赖于以下两个主要因素:

• 1. DBWR是否有足够的空间事件来写Flash Cache?
• 2. DBWR需要花费多长事件类写闪存设备?

第一个问题的答案依赖于DBWR当前的活动效率,可能也相应地依赖于你当期的磁盘阵列有多少可用的写带宽.但是,如果你的数据库已经遭遇或者将要遭遇”free buffer waits”,那么DB Flash Cache可能无法正常发挥作用,因为DBWR可能永远不会写Flash Cache.
第二个问题的答案依赖于闪存SSD的品质.通常你会选择使用拥有最小写延迟的闪存盘.那通常也意味着支持TRIM API调用,并且是使用SLC(Single Level Cell)的闪存.

Name (必填)

Mail (不会公开) (必填)

网站

表情：<(￣︶￣)> | (⊙ˍ⊙) | ＞﹏＜ | ｂ（￣▽￣）ｄ | （─.─||） | (^_-)

[ Ctrl+Enter提交 ]