ZFS：zdb -DDが正常に見えるにもかかわらず、重複除去に関するメモリの問題
Ubuntu 12.10、32GB RAM（ECC以外、本番システムにはECCがあります）および2x2TB Linux管理RAID1（RAIDZ1に移動されます）を搭載したマシンでZFSを実験してきました2TBのソフトRAID1デバイスでタンクを作成し、圧縮と重複除去を有効にして、数100GBのデータを保存しました。
約3.5倍の重複排除率を取得しました（これは実際に私のデータに意味があるため、それを使用したいのですが）空きメモリがまったくなくなったため、システムが使用できなくなりました。システムを再起動すると、すべてが正常に見えたので、数GBのデータを書き込みました。
次に、zfs_arc_maxを12GBに設定しました（明らかにメモリ消費が暴走したのは私だけではないため）。これにより、システムが応答しなくなるのを防ぎましたが、数GBを書き込むと、メモリ制限が最大になり、タンクへの書き込みが非常に遅くなりました。基本的に使用できません。
重複除去にはRAMが必要ですが、私の知る限り、これは
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
より多くのデータで更新されました。
OK、それで私は別のテストを実行しました-サーバーを再起動し、ボリュームなどをマウントしました：
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
そして、free -mは予想されるものを示し、バッファ/キャッシュと最初の行はused/freeについて同意しました。しかし、さらにいくつか遊んでみると、システムが不当に遅くなった（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----
r b 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はなんとかして記憶を消耗し続けます。ふew ...
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使用量。
- 計画と設計。
- パフォーマンス。
また参照してください： ZFS-重複排除されたzvolまたはデータセットを破棄すると、サーバーが停止します。回復する方法は？
それでは、DDTテーブルを調べてみましょう...
計算方法がわからない場合は、次を参照してください： 現時点でのZFS重複排除テーブルの大きさ
DDT-sha256-zap-duplicate: 615271 entries, size 463 on disk, 149 in core
615271 * 149 = 91675379-> 91675379/1024/1024 == 87.42メガバイト。
だからうーん...データセットにはあまり必要ないRAM.
注意すべきその他の項目。おそらくlz4圧縮ですが、ここで確認できるのはそれだけです。これがLinux仮想メモリサブシステムとZFSの間の相互作用であるかどうかを確認できますか？私はARCをそのままにしておきますが、Linux VM低速時の統計を確認します。これは、保存しているデータのタイプによって多少異なる場合があります。ファイルの種類はこれらですか？
目安としては、ディスクの1 RAMごとに約5 GBのTBを計画することをお勧めします。したがって、2 TBのデータがある場合、重複排除+ ARC + ZFSメタデータに対してのみ10 GBになります。それはあなたが望む答えではありませんが、努力する価値はありません。圧縮を有効にすると、ある程度の節約になります。これを見てください 記事
5GBは原則ですが、必ずしもそうである必要はありません。 64Kブロックを使用する場合、1TBあたり5GBのRAMが必要になると想定しています。ただし、ブロックサイズは512bと128Kの間で異なる場合があります。ソリューションはL2ARCおよびSSDドライブである可能性がありますが、高価になります。
実装固有の問題が発生している可能性があります。 Linuxの場合、 ZFS on Linux プロジェクトとzfs-Fuse実装があります。後者はかなり遅くなりますが、バージョン固有のコードの問題を除外するには、両方を使用してシナリオを試す必要があります。また、Nexenta/OpenIndianaリリース、またはSolaris 11.1 ODNインストールでテストする価値があるかもしれません。
ZFSのオンライン重複排除には、主なものであるプールへの書き込み時に、いくつかのアーキテクチャ上の問題、大量のメモリ消費、およびかなり高いCPU使用率があることに注意してください。 Windows Server 2012 for NTFS または BTRFS with bedup patch によって提供されるようなオフライン重複排除が使用パターンに適しているかどうかを確認する価値があるかもしれません。
とりあえず、0.6.2.1にはまだメモリフラグメント化のオーバーヘッドがたくさんあります。その重複排除部分は0.6.3で改善される予定です。私が開いた問題で提案されている現在の開発バージョンまたはパッチを試してみたいと思います： https://github.com/zfsonlinux/zfs/issues/208 。それがどうなるか見てみましょう。
更新：以下を参照してください-私は0.6.2を使用することを決定し、今のところ重複排除はありません。私のアプリケーションにとっては意味があると思うので、重複排除によって「安全」になるまで、新しいリリースのテストを続けます。
みんな、ありがとう！