差分
このページの2つのバージョン間の差分を表示します。
| 次のリビジョン | 前のリビジョン | ||
|
blog:2019:2019-12-31 [2019-12-31 21:09] Decomo 作成 |
blog:2019:2019-12-31 [2022-02-21 00:24] (現在) Decomo |
||
|---|---|---|---|
| 行 1: | 行 1: | ||
| - | ====== メモリ16GBは人権の今、ZFSの重複排除(zfs dedup)を解禁する ====== | + | ====== メモリ16GBは人権の今、ZFSの重複排除(dedup)を解禁する ====== |
| - | ZFSはそこそこ古いバージョン((ZFS Pool Version 21。2010年頃？))で重複排除機能(dedup)を備えたが、長らくのあいだ禁忌とされてきた。というのも、Chr〇meも真っ青のレベルでメモリを馬鹿食いするからだ。ZFSの他の機能同様、dedupも有効にした後の書き込みから機能するため、当初は問題なく動いてるように見えるが「なんか重いなぁ…」と気付いた時にはメモリが枯渇しているのだ。慌ててdedup=offにしても、既に重複排除された分はdedupが効き続けるため、メモリは減ったままなのだ。dedup地獄から抜け出すには、メモリを増設するかスワップを大量に割り当て、既存の重複排除が解除されるのをひたすら耐えるしかない。 | + | <WRAP box caution> |
| - | [[https:// | + | dedup有効状態で10ヵ月弱使ってみたけど、やっぱりまだ解禁しない方がよさげ。メモリ的には余裕だが、ファイル削除に時間がかかるようになったり微妙に怪しげな挙動をすることがある（何となくレコード毎に重複チェックが走り本当に削除するかどうかを決定しているような感じ。ファイルサイズと削除所用時間は比例する。要検証）。データの破損や消失は起きてないので、そういった意味での危険性はないが、有効にするなら何が起きても自己責任ってことで！ |
| + | </ | ||
| - | [[https:// | + | ZFSは2010年頃のPool Version 21で重複排除機能(dedup)を備えたが、本機能の使用は長らく禁忌とされてきた。というのも、Chr〇meも真っ青のレベルでメモリを馬鹿食いするからだ。ZFSの他の機能同様、dedupも有効にした後の書き込みから機能するため、当初は問題なく動いてるように見える。が、徐々にメモリが使われて行き「なんか重いなぁ…」と気付いた時には既に遅し、メモリが枯渇しているのである。慌ててdedup=offにしても、既に重複排除された分は効き続けるため、メモリは減ったままというオマケ付き。dedup地獄から抜け出すには、メモリを増設するかスワップを大量に割り当て、既存の重複排除が解除されるのをひたすら耐えるしかない。 |
| + | |||
| + | そんな訳でdedupの実用は難しかったのだけども、[[https:// | ||
| + | |||
| + | [[https:// | ||
| dedupを有効にするプール'' | dedupを有効にするプール'' | ||
| 行 53: | 行 58: | ||
| '' | '' | ||
| - | 標準でdedupはSHA-256を使うようになっているが、manを見る限りSkeinはSHA-256/ | + | dedupは標準でSHA-256を使うようになっているが、manを見る限りSkeinはSHA-256/ |
| - | 別プールにあるISOイメージやらインストーラやらが詰まってる493GBのフォルダを、dedup有効にしたプールにコピーした結果が以下。 | + | その後、別プールにあるISOイメージやらインストーラやらが詰まってる493GBのフォルダを、dedup有効のプールにコピーした結果が以下。 |
| < | < | ||
| $ zpool list zhome | $ zpool list zhome | ||
| 行 61: | 行 66: | ||
| zhome 7.27T 1.64T 5.62T - | zhome 7.27T 1.64T 5.62T - | ||
| </ | </ | ||
| + | |||
| + | 重複排除率が1.11xってのは……たぶん2.00xならdedupで実使用量が半分になったって事だろうから、(重複排除できたサイズ)=(1-(1/ | ||
| この時のメモリ使用量の変化は下図のとおり。 | この時のメモリ使用量の変化は下図のとおり。 | ||
| {{ : | {{ : | ||
| - | '' | + | ARCサイズは'' |
| - | 493GBで5GBって冒頭の概算の2倍消費しとるやんけ！と思ったが、Skeinは512bitハッシュなので比率で考えたら見事に概算通りの結果となった。そう考えると、メモリ64GB程度ではdedupを使うにはまだ心許ない感じがするなぁ……（何というオチ）。ちなみに、将来[[https:// | + | データ493GBでハッシュ5GBって冒頭の概算の2倍消費しとるやんけ！と思ったが、Skeinは512bitハッシュなので比率で考えたら見事に概算通りの結果となった。そう考えると、メモリ64GB程度ではdedupを使うにはまだ心許ない感じがするなぁ……（何というオチ）。ちなみに、将来[[https:// |
| まぁ、せっかくdedup有効にしてみたんだし、しばらく運用してみよう。NVMeなSSDも載ってるので、最悪そっちに大容量スワップ作れば何とかなるだろう。 | まぁ、せっかくdedup有効にしてみたんだし、しばらく運用してみよう。NVMeなSSDも載ってるので、最悪そっちに大容量スワップ作れば何とかなるだろう。 | ||
| + | |||
| + | ---- | ||
| + | (2020-01-06 追記) | ||
| + | |||
| + | dedup有効後、6日ほど経ったのでtopを見てみたら、ARCが20GBに戻ってた…。ARCからハッシュキャッシュから取られる訳ではなさそう？ちゃんと調べてみないと分かりませんな……。 | ||
| + | < | ||
| + | last pid: 26323; | ||
| + | 51 processes: | ||
| + | CPU: 0.8% user, 0.0% nice, 0.3% system, | ||
| + | Mem: 295M Active, 1465M Inact, 25G Wired, 35G Free | ||
| + | ARC: 20G Total, 11G MFU, 6802M MRU, 1530K Anon, 369M Header, 1446M Other | ||
| + | 17G Compressed, 24G Uncompressed, | ||
| + | Swap: | ||
| + | </ | ||
| + | |||
| + | |||
| + | ===== 参考サイト ===== | ||
| + | |||
| + | * [[https:// | ||
| + | * [[https:// | ||
| + | * [[https:// | ||