blog:2022:2022-02-21

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

次のリビジョン 		前のリビジョン
blog:2022:2022-02-21 [2022-02-21 23:57]
Decomo 作成 		blog:2022:2022-02-21 [2022-03-04 10:51] (現在)
Decomo
行 1: 行 1:
-====== ZFS圧縮のLZ4とZStandardを簡易比較（ZStdがよさげ） ======+====== ZFS圧縮のLZ4とZStandardを簡易比較（zstdがよさげ） ======
  
-ZFSerの皆様におかれましては、OpenZFS 2.0で圧縮アルゴリズムにZStandardが追加されたのは周知の事実だろう。compressionの値として''zstd-N''と''zstd-fast-N''が指定できるようになったが、設定値の関係性は以下のとおり。+ZFSerの皆様におかれましては、OpenZFS 2.0で圧縮アルゴリズムにZStandardが追加されたのは周知の事実だろう。compressionの値として''zstd-N''と''zstd-fast-N''が指定できるようになったが、設定値と圧縮率の関係性は以下のとおり。
  
 |（速度重視）←　　  | 設定値 |  　　→（圧縮重視）| |（速度重視）←　　  | 設定値 |  　　→（圧縮重視）|
 |  zstd-fast-1000 ～ zstd-fast-1 / zstd-1 ～ zstd-19  ||| |  zstd-fast-1000 ～ zstd-fast-1 / zstd-1 ～ zstd-19  |||
  
-''zstd''と''zstd-fast''で数値の意味合いが逆転しているようにも見えるが（というか設定値上はそういう風にしか見えないのだが）、''zstd-fast''の方は負数を表しており、-1000が最小でスーパー速度重視という意味で一貫性が取れている。+''zstd''と''zstd-fast''で数値の関係性が逆転しているように見えるが（というか設定値上はそういう風にしか見えないのだが）、''zstd-fast''の方は負数を表しており、-1000が最小でスーパー速度重視ということなので一貫性が取れている。
  
-LZ4よりは処理負荷が高いとされているZStandardの実力がどの程度か、簡易的にテストした。+ZStandardはLZ4より圧縮率が高く、それに応じて処理負荷も若干高いとされている。実際のところどんなものか、簡易的にテストした。
  
-個人的にアーカイブ用途に使いたいので、圧縮率重視ってことで''zstd''のみを対象とした。だいぶてきとーな実験なので、あくまで傾向を掴むもの程度で見て欲しい。+個人的にアーカイブ用途に使いたいので、圧縮率重視ってことで''zstd''のみが対象。だいぶてきとーな実験なので、あくまで傾向を掴むもの程度で見て欲しい。
  
 ZFSの主要開発者の1人、Allan Judeによる[[https://docs.google.com/spreadsheets/d/1TvCAIDzFsjuLuea7124q-1UtMd0C9amTgnXm2yPtiUQ|真っ当なベンチマーク]]も参照されたし。 ZFSの主要開発者の1人、Allan Judeによる[[https://docs.google.com/spreadsheets/d/1TvCAIDzFsjuLuea7124q-1UtMd0C9amTgnXm2yPtiUQ|真っ当なベンチマーク]]も参照されたし。
行 61: 行 61:
 まず言えることは''zstd-3''のバランスの良さ。LZ4と遜色ない速度にもかかわらず、圧縮率は有意に高い。さすが、''compress=zstd''とした時に使われるレベルだけある。''gzip-9''より縮むのに大分速いってのは特筆すべき。 まず言えることは''zstd-3''のバランスの良さ。LZ4と遜色ない速度にもかかわらず、圧縮率は有意に高い。さすが、''compress=zstd''とした時に使われるレベルだけある。''gzip-9''より縮むのに大分速いってのは特筆すべき。
  
-圧縮率最重視の''zstd-19''が当然ながら最も縮むが、速度が大分厳しい感じ。少なくとも今回のテストデータでは、処理に見合うだけの圧縮効果が得られているとは言い難い。仮に最新CPUで速度が10倍になったとしても、250MB/s程度なので使いどころが難しそう。費用対効果が高いのは''zstd-7''、状況によっては''zstd-15''もなくはないかな。+圧縮率最重視の''zstd-19''が当然ながら最も縮むが、速度が大分厳しい感じ。少なくとも今回のテストデータでは、処理時間に見合うだけの効果が得られているとは言い難い。仮に最新CPUで速度が10倍になったとしても、250MB/s程度でボトルネックとなる可能性が高く使いどころが難しそう。費用対効果が高いのは''zstd-7''、状況によっては''zstd-15''もなくはないかな。 
 + 
 +===== recordsizeによる圧縮率の変化 =====
  
 ついでに、圧縮は''recordsize''が大きいほど効果的とされているので、その影響も軽く測定。 ついでに、圧縮は''recordsize''が大きいほど効果的とされているので、その影響も軽く測定。
行 67: 行 69:
 LZ4とZStandardのそれぞれで、レコードサイズを512kから1Mに変更した時の圧縮後容量の差分を求めたのが下表。 LZ4とZStandardのそれぞれで、レコードサイズを512kから1Mに変更した時の圧縮後容量の差分を求めたのが下表。
  
-^  圧縮方法  ^  削減量(MiB)  ^  無圧縮容量に占める削減割合  ^ +^  圧縮方法  ^  recsize  ^  圧縮後容量(MiB)  ^  128kとの差分(MiB)  ^  無圧縮容量に占める削減割合  ^ 
-| lz4 | 677.5 | 0.13% | +| lz4 |  128k |  495251.3 |  -  |  -  | 
-| zstd-7 | 935.2 | 0.18% |+| ::: |  512k |  495145.0 |  -106.3 |  -0.02%  | 
 +| ::: |    1M |  495251.4 |  +0.1 |  +0.00%  | 
 +| zstd-7 |  128k |  490354.9 |  -  |  -  | 
 +| :::    |  512k |  488842.4 |  -1512.5 |  -0.29%  | 
 +| :::    |    1M |  487907.2 |  -2447.7 |  -0.48%  |
  
-確かにレコードサイズが大きい方が効率的に圧縮できるようだ。割合で見ると微々たるものだが、''recordsize''を変えるだけで恩恵が得られるのはありがたい。+なぜかLZ4のレコードサイズ1MBの時は圧縮率が下がってるけど、概ねレコードサイズが大きくなるほど圧縮率も向上するようだ。割合で見ると微々たるものだが、レコードサイズを変えるだけで恩恵が得られるのはありがたい。実のところ、レコードサイズを大きくすると実データに占めるメタデータ割合（ハッシュの量）が減り、プール容量的にはこちらの影響の方が大きかったりする（参考：[[blog:2022:2022-02-24]]）
  
 とりあえず、互換性を気にしなくていい環境では、lz4の代わりに積極的にzstdを使っていくのが良さそう。可能な限りrecordsizeも大きくしていこう（ただし、FreeBSDはレコードサイズが128k超のファイルシステムからブート出来ない点には注意が必要。） とりあえず、互換性を気にしなくていい環境では、lz4の代わりに積極的にzstdを使っていくのが良さそう。可能な限りrecordsizeも大きくしていこう（ただし、FreeBSDはレコードサイズが128k超のファイルシステムからブート出来ない点には注意が必要。）
  • blog/2022/2022-02-21.1645455467.txt.gz
  • 最終更新: 2022-02-21 23:57
  • by Decomo