Chinaunix首页 | 论坛 | 博客
  • 博客访问: 361004
  • 博文数量: 38
  • 博客积分: 256
  • 博客等级: 入伍新兵
  • 技术积分: 846
  • 用 户 组: 普通用户
  • 注册时间: 2012-12-14 23:21
文章分类

全部博文(38)

文章存档

2015年(1)

2014年(1)

2013年(28)

2012年(8)

我的朋友

分类: 云计算

2013-08-11 14:07:23

闲话缓存:ZFS 读缓存深入研究-ARC(二)

Solaris ZFS ARC的改动(相对于IBM ARC

如我前面所说,ZFS实现的ARC和IBM提出的ARC淘汰算法并不是完全一致的。在某些方面,它做了一些扩展:

·         ZFS ARC是一个缓存容量可变的缓存算法,它的容量可以根据系统可用内存的状态进行调整。当系统内存比较充裕的时候,它的容量可以自动增加。当系统内存比较紧张(其它事情需要内存)的时候,它的容量可以自动减少。

·         ZFS ARC可以同时支持多种块大小。原始的实现假设所有的块都是相同大小的。

·         ZFS ARC允许把一些页面锁住,以使它们不会被淘汰。这个特性可以防止缓存淘汰一些正在使用的页面。原始的设计没有这个特性,所以在ZFS ARC中,选择淘汰页面的算法要更复杂些。它一般选择淘汰最旧的可淘汰页面。

有一些其它的变更,但是我把它们留在对arc.c这个源文件讲解的演讲中。

L2ARC

L2ARC保持着上面几个段落中没涉及到的一个模型。ARC并不自动地把那些淘汰的页面移进L2ARC,而是真正淘汰它们。虽然把淘汰页面自动放入L2ARC是一个看起来正确的逻辑,但是这却会带来十分严重负面影响。首先,一个突发的顺序读会覆盖掉L2ARC缓存中的很多的页面,以至于这样的一次突发顺序读会短时间内淘汰很多L2ARC中的页面。这是我们不期望的动作。

另一个问题是:让我们假设一下,你的应用需要大量的堆内存。这种更改过的Solaris ARC能够调整它自己的容量以提供更多的可用内存。当你的应用程序申请内存时,ARC缓存容量必须 变得越来越小。你必须立即淘汰大量的内存页面。如果每个页面被淘汰的页面都写入L2ARC,这将会增加大量的延时直到你的系统能够提供更多的内存,因为你必须等待所有淘汰页面在被淘汰之前写入L2ARC。

L2ARC机制用另一种稍微不同的手段来处理这个问题:有一个叫l2arc_feed_thread会遍历那些很快就会被淘汰的页面(LRU和LFU链表的末尾一些页面),并把它们写入一个8M的buffer中。从这里开始,另一个线程write_hand会在一个写操作中把它们写入L2ARC。

这个算法有以下一些好处:释放内存的延时不会因为淘汰页面而增加。在一次突发的顺序读而引起了大量淘汰页面的情况下,这些数据块会被淘汰出去在l2arc——feed_thread遍历到那两个链表结尾之前。所以L2ARC被这种突发读污染的几率会减少(虽然不能完全的避免被污染)。

结论

Adjustable Replacement Cache的设计比普通的LRU缓存设计有效很多。Megiddo和 Modha用它们的Adaptive Replacement Cache得出了更好的命中率。ZFS ARC利用了它们的基本操作理论,所以命中率的好处应该与原始设计差不多。更重要的是:如果这个缓存算法帮助它们得出更好的命中率时,用SSD做大缓存的想法就变得更加切实可行。

想了解更多?

1.      The theory of ARC operation in One Up on LRU, written by Megiddo and Modha, IBM Almanden Research Center

2.      ZFS ARC源代码:

阅读(6225) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~