no-image

Btrfsの透過圧縮を使うと、実際のところ,どの程度パフォーマンスが改善するのか試してみた

Btrfsに搭載されている
透過圧縮のマウントオプションですが

圧縮を利用することによってディスクIOの負担が減り
パフォーマンスが改善するという情報が流れています。

確かにベンチマークの結果では読み取り性能などが向上しているようですが
実際のユースケースではどうなるのでしょうか?

調べても数年前の記事しか見当たらなかったので
実際に自分で調査しました。

zstd圧縮を有効にして、様々なデータを実測して比較

比較方法は単純。

ユーザーのホームフォルダ全体に
ファイルごとのzstd圧縮を有効にしたユーザーと

デフォルト状態のユーザーとで
様々なコマンドを試してみて実際の時間を計測します。

圧縮コマンドはナウいやり方を採用します。

btrfs property set ./zstdTest compression zstd
btrfs property set ./zstd15Test compression zstd:15

まずは書き込み時間をベンチマーク

とりあえずシンプルに書き込み時間をベンチマークしてみます。

# default
dd if=/dev/zero of=./tmp bs=512M count=10
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 8.63559 s, 622 MB/s
# zstd
dd if=/dev/zero of=./tmp bs=512M count=10
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 3.81261 s, 1.4 GB/s
# zstd:15
dd if=/dev/zero of=./tmp bs=512M count=10
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 4.71192 s, 1.1 GB/s

・・・えっ!?

ちょっと予想外の結果に戸惑っています。

なるほど
こういう事でしたら確かにパフォーマンスの上昇は期待できそうです。

読み込み時間をベンチマーク

次に読み込みの方のベンチマークです。

dd if=tmp of=/dev/null
# default
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 13.1624 s, 408 MB/s
# zstd
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 18.7503 s, 286 MB/s
# zstd:15
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 20.8998 s, 257 MB/s

うーん遅くなる?
10プロセス並行してみます。

# 512Mのファイルを10個作成
dd if=/dev/zero of=./tmp1 bs=512M count=1 #tmp10まで作成
# 10プロセス並行して読み込む
/usr/bin/time -p /bin/bash -c "dd if=tmp1 of=/dev/null & dd if=tmp2 of=/dev/null & dd if=tmp3 of=/dev/null & dd if=tmp4 of=/dev/null & dd if=tmp5 of=/dev/null & dd if=tmp6 of=/dev/null & dd if=tmp7 of=/dev/null & dd if=tmp8 of=/dev/null & dd if=tmp9 of=/dev/null & dd if=tmp10 of=/dev/null & wait"
# default
real 15.27
user 12.37
sys 7.66
# zstd
real 5.08
user 8.65
sys 5.36
# zstd:15
real 4.40
user 7.36
sys 4.23

なるほど
並列化すればCUPの限界まで読み込み時間を加速させられそうですね。
しかし残念ながら理論上最速になりそうなlz4には未対応。

ここで裏技を発見

先程のベンチマークですが
読み書きの速度を倍速にする裏技を発見しました。
(まあ裏技という程でもありませんが)

Btrfsの圧縮・解凍はシングルスレッドで動作するので
実はハイパースレッディングを無効化すると1プロセス辺りの圧縮と解凍の速度が倍になります。

ベンチマーク結果がストレージ性能を下回ってしまう場合には
ハイパースレッディングを無効化して運用するのも手かもしれません。

この記事が皆さんのお役に立てば幸いです。