delphij's Chaos

选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……

10 Mar 2011

ZFS dedup初步测试

最近做一个存储的项目,顺手在家测试了一下实际数据的dedup。操作系统是 FreeBSD 8.2 配合一组总共大约3MB的patch来跑ZFS v28,硬件是 Atom D510 配合 4G 内存。

初步测试的主要目的是取得一些感性认识而不是进行定量分析。

首先是支持的算法。ZFS默认使用的是SHA256,不做校验;刚开始测试的时候不懂事,开了校验,发现速度慢的没法忍受(需要继续研究到底是为什么,个人评估应该是因为校验本身触发的读操作导致),关闭校验则会好很多。

ZFS提供了一个事先评估dedup效果的方法,使用zdb -S pool名字来看。

为了避免过分dedup导致数据存储可靠性方面的问题(例如,有某块数据实际上在pool中有200个引用,但实际上只有一份,那么一旦那个数据块出问题的话就会导致200份都出问题),可以设置 dedupditto。

在事后可以用zdb -DD pool名字来查看实际的效果。

下面是某pool中实际的效果:


DDT-sha256-zap-duplicate: 1034868 entries, size 440 on disk, 142 in core
DDT-sha256-zap-unique: 3745115 entries, size 461 on disk, 148 in core

DDT histogram (aggregated over all DDTs):

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    3.57M    151G    117G    123G    3.57M    151G    117G    123G
     2     908K   27.5G   22.7G   24.3G    1.91M   63.0G   52.6G   56.1G
     4    57.1K   1.15G    862M    983M     269K   5.37G   3.84G   4.40G
     8    40.5K    436M    228M    320M     428K   4.75G   2.47G   3.43G
    16    4.73K   36.2M   20.6M   31.3M    89.2K    687M    387M    591M
    32      295   2.37M    901K   1.66M    12.1K   99.1M   36.3M   69.5M
    64      100    708K    224K    524K    8.52K   58.6M   19.0M   44.7M
   128       20     10K     10K     80K    3.46K   1.73M   1.73M   13.8M
   256       13     76K   39.5K     76K    4.77K   26.2M   13.5M   27.1M
   512       11   18.5K     13K     48K    8.05K   12.5M   8.90M   34.9M
    1K        8      4K      4K     32K    11.8K   5.91M   5.91M   47.3M
    2K        6     20K   5.50K     24K    14.1K   44.8M   12.6M   56.6M
    4K        3   1.50K   1.50K     12K    15.2K   7.59M   7.59M   60.7M
    8K        1     512     512      4K    16.0K   7.98M   7.98M   63.8M
   16K        1     512     512      4K    30.9K   15.4M   15.4M    124M
   64K        1     512     512      4K    83.5K   41.8M   41.8M    334M
 Total    4.56M    180G    141G    149G    6.45M    225G    176G    188G

dedup = 1.27, compress = 1.28, copies = 1.07, dedup * compress / copies = 1.52

过几天找个Fusion-IO来在iSCSI上实际跑些VM试试看。


Archived: 5 Comments

macafee | March 10, 2011 1:30 AM

感觉delphij开始有幽默感了,是不是快要有BABY了的缘故?

ghw | May 18, 2011 8:06 AM

ZFS对处理器依赖没那么大的?为什么用凌动也没事啊?

joyway | June 7, 2011 8:20 AM

怎么没有ATOM的CPU占用率,速度等方面的信息啊?不知道ATOM跑dedup+compress会不会很卡?拷文件的速度是多少呢?

刚刚想安装一个文件服务器,家用的,用来保存小孩的照片的。想用ZFS来保证数据安全,想开dedup, 至于压缩倒是不一定要开,必竟图片也没有什么好压缩的。现在问题是想搞一个没有风扇的系统,放在房间里。但是怕ATOM的系统开dedup反应会很慢。刚刚google到你有做测试,就来向你请教了。

要是能发到这些信息到我邮箱里,不胜感激。

Xin LI | June 7, 2011 10:15 AM

我实际用的情况,没有 ECC 内存有时候还是会丢数据的(不过因为我有异地备份,所以并没有真的导致损失)。

照片 dedup 的意义很可能不大,你可以先用 zdb -DD 来看看效果。还有一个办法是让机器夜里自己去跑 dedup (启用 dedup,然后重写一遍数据,然后再关闭)。Atom跑 dedup+compress 肯定不快,主要是内存太小。

likuku | February 8, 2012 10:31 PM

【为了避免过分dedup导致数据存储可靠性方面的问题(例如,有某块数据实际上在pool中有200个引用,但实际上只有一份,那么一旦那个数据块出问题的话就会导致200份都出问题),可以设置 dedupditto。】

假若使用mirror/raidz/raidz2,是否就缓解了这个状况呢?