ZFS:内存问题与重复数据删除即使zdb -DD看起来不错

我一直在使用Ubuntu 12.10,32GB RAM(非ECC,生产系统将具有ECC)和一个2x2TB Linuxpipe理的RAID1(将移至RAIDZ1进行生产)的机器上对ZFS进行实验。 我刚刚在2TB软RAID1设备上创build了储jar,启用了压缩和重复数据删除function,并存储了几百GB的数据。

我得到了大约3.5倍的重复数据删除比率(对我的数据来说真的很有意义,这就是为什么我想使用它),但是根本没有剩余的内存,系统变得无法使用。 重新启动系统,一切似乎都很好,然后我写了几GB的数据,一样的东西。

然后我把zfs_arc_max设置为12GB(因为显然我不是唯一一个有内存消耗不足的人),这样可以避免系统变得没有响应,但是写入内存极限并写入内存极限的几GB变得非常慢,基本上无法使用。

我知道,重复数据删除需要内存,但据我所知,这

DDT-sha256-zap-duplicate: 615271 entries, size 463 on disk, 149 in core DDT-sha256-zap-unique: 846070 entries, size 494 on disk, 159 in core DDT histogram (aggregated over all DDTs): bucket allocated referenced ______ ______________________________ ______________________________ refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE ------ ------ ----- ----- ----- ------ ----- ----- ----- 1 826K 83.5G 51.7G 52.9G 826K 83.5G 51.7G 52.9G 2 363K 34.6G 17.8G 18.5G 869K 81.9G 41.3G 43.0G 4 138K 14.1G 8.89G 9.11G 654K 66.4G 41.0G 42.1G 8 49.0K 3.94G 2.25G 2.34G 580K 44.3G 25.3G 26.4G 16 37.2K 3.96G 3.06G 3.10G 865K 90.1G 69.9G 70.8G 32 9.81K 854M 471M 488M 464K 40.5G 21.9G 22.7G 64 1.84K 160M 80.8M 85.1M 148K 11.8G 5.99G 6.33G 128 1.13K 60.4M 24.7M 27.7M 218K 11.2G 4.70G 5.26G 256 545 52.9M 30.9M 32.1M 169K 15.5G 9.00G 9.36G 512 120 7.17M 4.19M 4.51M 84.5K 5.09G 2.96G 3.18G 1K 368 40.0M 19.0M 19.7M 480K 52.2G 24.8G 25.7G 2K 16 401K 23K 76K 46.4K 1.31G 73.5M 226M 4K 8 5K 4K 32K 39.9K 24.6M 20.0M 160M Total 1.39M 141G 84.3G 86.6G 5.32M 504G 299G 308G 

意味着表格只需要大约90MB的内存,所以我不知道发生了什么。 我有一个相同的服务器上没有重复数据删除相同的设置,似乎工作正常…

我真的很感激任何帮助(除了“禁用重复数据删除”,因为它确实对我的数据真的有意义;))! 更多数据:

 tank type filesystem - tank creation Thu Jan 16 13:17 2014 - tank used 342G - tank available 1.67T - tank referenced 341G - tank compressratio 1.64x - tank mounted yes - tank quota none default tank reservation none default tank recordsize 128K default tank mountpoint / tank default tank sharenfs off default tank checksum on default tank compression lzjb local tank atime off local tank devices on default tank exec on default tank setuid on default tank readonly off default tank zoned off default tank snapdir hidden default tank aclinherit restricted default tank canmount on default tank xattr sa local tank copies 1 default tank version 5 - tank utf8only off - tank normalization none - tank casesensitivity sensitive - tank vscan off default tank nbmand off default tank sharesmb off default tank refquota none default tank refreservation none default tank primarycache all default tank secondarycache all default tank usedbysnapshots 36.9M - tank usedbydataset 341G - tank usedbychildren 702M - tank usedbyrefreservation 0 - tank logbias latency default tank dedup on local tank mlslabel none default tank sync standard default tank refcompressratio 1.64x - tank written 308K - tank snapdev hidden default 

更多的数据更新。

好的,所以我跑了另一个testing – 重新启动服务器,安装量等:

  total used free shared buffers cached Mem: 32138 457 31680 0 19 66 -/+ buffers/cache: 372 31766 Swap: 7812 0 7812 

和arcstats

 4 1 0x01 84 4032 7898070146 560489175172 name type data hits 4 1059 misses 4 185 demand_data_hits 4 0 demand_data_misses 4 0 demand_metadata_hits 4 971 demand_metadata_misses 4 49 prefetch_data_hits 4 0 prefetch_data_misses 4 7 prefetch_metadata_hits 4 88 prefetch_metadata_misses 4 129 mru_hits 4 476 mru_ghost_hits 4 0 mfu_hits 4 495 mfu_ghost_hits 4 0 deleted 4 9 recycle_miss 4 0 mutex_miss 4 0 evict_skip 4 0 evict_l2_cached 4 0 evict_l2_eligible 4 0 evict_l2_ineligible 4 2048 hash_elements 4 176 hash_elements_max 4 176 hash_collisions 4 0 hash_chains 4 0 hash_chain_max 4 0 p 4 6442450944 c 4 12884901888 c_min 4 1610612736 c_max 4 12884901888 size 4 1704536 hdr_size 4 101424 data_size 4 1448960 other_size 4 154152 anon_size 4 16384 anon_evict_data 4 0 anon_evict_metadata 4 0 mru_size 4 1231872 mru_evict_data 4 206336 mru_evict_metadata 4 849408 mru_ghost_size 4 0 mru_ghost_evict_data 4 0 mru_ghost_evict_metadata 4 0 mfu_size 4 200704 mfu_evict_data 4 0 mfu_evict_metadata 4 4096 mfu_ghost_size 4 16384 mfu_ghost_evict_data 4 0 mfu_ghost_evict_metadata 4 16384 l2_hits 4 0 l2_misses 4 0 l2_feeds 4 0 l2_rw_clash 4 0 l2_read_bytes 4 0 l2_write_bytes 4 0 l2_writes_sent 4 0 l2_writes_done 4 0 l2_writes_error 4 0 l2_writes_hdr_miss 4 0 l2_evict_lock_retry 4 0 l2_evict_reading 4 0 l2_free_on_write 4 0 l2_abort_lowmem 4 0 l2_cksum_bad 4 0 l2_io_error 4 0 l2_size 4 0 l2_asize 4 0 l2_hdr_size 4 0 l2_compress_successes 4 0 l2_compress_zeros 4 0 l2_compress_failures 4 0 memory_throttle_count 4 0 duplicate_buffers 4 0 duplicate_buffers_size 4 0 duplicate_reads 4 0 memory_direct_count 4 0 memory_indirect_count 4 0 arc_no_grow 4 0 arc_tempreserve 4 0 arc_loaned_bytes 4 0 arc_prune 4 0 arc_meta_used 4 1498200 arc_meta_limit 4 3221225472 arc_meta_max 4 1449144 

玩了一下,直到ARC命中vfs_arc_max(12GB):

 4 1 0x01 84 4032 7898070146 1406380500230 name type data hits 4 7338384 misses 4 117090 demand_data_hits 4 4841648 demand_data_misses 4 10072 demand_metadata_hits 4 2423640 demand_metadata_misses 4 35334 prefetch_data_hits 4 37879 prefetch_data_misses 4 65420 prefetch_metadata_hits 4 35217 prefetch_metadata_misses 4 6264 mru_hits 4 2672085 mru_ghost_hits 4 301 mfu_hits 4 4615778 mfu_ghost_hits 4 1183 deleted 4 9 recycle_miss 4 1022 mutex_miss 4 17 evict_skip 4 2 evict_l2_cached 4 0 evict_l2_eligible 4 1977338368 evict_l2_ineligible 4 751589376 hash_elements 4 166822 hash_elements_max 4 166828 hash_collisions 4 59458 hash_chains 4 21504 hash_chain_max 4 4 p 4 55022931 c 4 12652319216 c_min 4 1610612736 c_max 4 12884901888 size 4 12327222416 hdr_size 4 55933440 data_size 4 12149027328 other_size 4 122261648 anon_size 4 1056256 anon_evict_data 4 0 anon_evict_metadata 4 0 mru_size 4 6481734656 mru_evict_data 4 6220393984 mru_evict_metadata 4 188646912 mru_ghost_size 4 1902724096 mru_ghost_evict_data 4 1871710720 mru_ghost_evict_metadata 4 31013376 mfu_size 4 5666236416 mfu_evict_data 4 5643978240 mfu_evict_metadata 4 16081408 mfu_ghost_size 4 708022272 mfu_ghost_evict_data 4 680676352 mfu_ghost_evict_metadata 4 27345920 l2_hits 4 0 l2_misses 4 0 l2_feeds 4 0 l2_rw_clash 4 0 l2_read_bytes 4 0 l2_write_bytes 4 0 l2_writes_sent 4 0 l2_writes_done 4 0 l2_writes_error 4 0 l2_writes_hdr_miss 4 0 l2_evict_lock_retry 4 0 l2_evict_reading 4 0 l2_free_on_write 4 0 l2_abort_lowmem 4 0 l2_cksum_bad 4 0 l2_io_error 4 0 l2_size 4 0 l2_asize 4 0 l2_hdr_size 4 0 l2_compress_successes 4 0 l2_compress_zeros 4 0 l2_compress_failures 4 0 memory_throttle_count 4 0 duplicate_buffers 4 0 duplicate_buffers_size 4 0 duplicate_reads 4 0 memory_direct_count 4 0 memory_indirect_count 4 1947 arc_no_grow 4 0 arc_tempreserve 4 0 arc_loaned_bytes 4 0 arc_prune 4 0 arc_meta_used 4 462466704 arc_meta_limit 4 3221225472 arc_meta_max 4 465357280 

并免费-m显示什么是预期的,缓冲区/caching和第一行约定使用/免费。 但是,多玩一些导致系统变得不合理地慢(复制1GB的时间)和

  total used free shared buffers cached Mem: 32138 31923 215 0 6 15442 -/+ buffers/cache: 16473 15665 Swap: 7812 0 7812 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- rb swpd free buff cache si so bi bo in cs us sy id wa 1 1 308 3774708 27204 9464052 0 0 386 271 72 348 1 2 83 15 

卸载ZFS卷并卸载内核模块可以释放所有的内存…所以对我来说,它看起来像是某种内存泄漏:zfs_arc_max被设置,arcstats说这个限制被观察到(见下文),但ZFS不知何故继续吃掉记忆。 呼…

  time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c 14:08:08 0 0 0 0 0 0 0 0 0 9.8G 10G 

在ZFS上重复数据并不总是值得的 。 好吧,这是不值得的…我知道这是吸引人的,性感的,听起来似乎是一个伟大的卖点…但在什么成本?

  • 可预测性。
  • 稳定性。
  • RAM使用情况。
  • 规划和devise。
  • 性能。

另请参阅: ZFS – 销毁重复数据删除的zvol或数据集将停止服务器。 如何恢复?

那我们来看看你的滴滴涕表
如果您不确定如何计算,请参阅: 目前我的ZFS重复数据删除表有多大?

DDT-sha256-zap-duplicate: 615271 entries, size 463 on disk, 149 in core

615271 * 149 = 91675379 – > 91675379/1024/1024 == 87.42兆字节。

所以嗯…数据集所需的内存不多。

其他项目要注意。 你可能应该使用lz4压缩,但这是我从这里可以看到的所有东西。 你能否看到这是Linux虚拟内存子系统和ZFS之间的交互? 我会保持ARC的地方…但速度慢的时候检查Linux虚拟机的统计数据。 这可能取决于你正在存储什么types的数据。 这些是什么types的文件?

一个好的经验法则是为每1 TB的磁盘规划大约5 GB的RAM。 因此,如果您有2TB的数据,则只有10GB才能用于重复数据删除+ ARC + ZFS元数据。 这不是你想要的答案,但这不值得。 启用压缩后,您仍然可以节省一些成本。 看看这篇文章

5GB是一般规则,但不一定是真的。 假设您使用64K块,我们假设每个1TB需要5GB的RAM。 但在512B和128K之间的块大小可以不同。 解决scheme可能是L2ARC和SSD驱动器,但价格昂贵。

您可能会遇到实施特定的问题。 对于Linux, 在Linux项目ZFS以及zfs-fuse实现。 后者是相当慢,但你应该尝试你的scheme与他们两个排除特定于版本的代码问题。 另外,Nexenta / OpenIndiana发行版甚至Solaris 11.1 ODN安装也许值得一试。

请记住,ZFS的在线重复数据删除存在一些体系结构问题,大量内存消耗,并在写入主池时占用相当高的CPU利用率。 可能需要检查Windows Server 2012 for NTFS或带有补丁修补程序的BTRFS提供的脱机重复数据删除是否更适合您的使用模式。

现在回答这个问题 – 很明显,0.6.2.1仍然有很多内存碎片开销,重复数据删除部分在0.6.3中会有所改进。 我想我会尝试当前的开发版本或在我打开的问题中build议的修补程序: https : //github.com/zfsonlinux/zfs/issues/2083 。 让我们看看如何。

更新:见下文 – 我决定去0.6.2,现在没有重复数据删除。 我将继续testing新版本,直到我对重复数据删除“安全”,因为我相信这对我的应用程序是有意义的。

感谢大家!