OSX ファイルシステムのデータセットにおける OpenZFS のパフォーマンスの問題

Question

tl;dr - 私の ZFS RAIDZ2 アレイは、 でbs=128Kまたはそれ以上を指定すると、7.5+ GB/s で読み取り、2.0+ GB/s で書き込みますdd。OS X は に従って 1K を想定しておりstat -f %k .、私のすべての は約 300MB/s です。ddでも同じパフォーマンスが得られますbs=1k。 でさえ、bs=4kdd では 1.1GB/s になります。

一般的な I/O を少なくとも 1GB/秒に向上させるにはどうすればよいですか?

--

詳細：

私は、12 コア 64GB Mac Pro に、Thunderbolt 2 (ツイン Areca 8050T2) 経由で、OSX (v1.31r2) ファイルシステム (v5000) 上の 16 ドライブ SATA3 RAIDZ2 OpenZFS を実行しています。

ZFS ファイルシステムは、ashift=12(4096 バイト ブロックの Advanced Format HDD)と で作成されましたrecordsize=128k。

OS X のアレイおよびデフォルトのコマンドを使用したターミナルからの転送速度は約 300 MB/秒です (コピーされるファイルは 10 GB のランダム データであることに注意してください)。

通常コピー:

Titanic:lb-bu admin$ time cp big-test.data /dev/null

real    0m23.730s
user    0m0.005s
sys     0m12.123s

≈ 424 MB/秒

--

ddとbs=1k：

Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=1024
9841180+0 records in
9841180+0 records out
10077368320 bytes transferred in 32.572506 secs (309382653 bytes/sec)

real    0m32.575s
user    0m1.880s
sys     0m30.695s

≈ 309 MB/秒

--

ddとbs=4k

Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=4096
2460295+0 records in
2460295+0 records out
10077368320 bytes transferred in 8.686014 secs (1160183301 bytes/sec)

real    0m8.688s
user    0m0.460s
sys     0m8.228s

≈1.16 GB/秒

- ddとbs=2m：

Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=2m
4805+1 records in
4805+1 records out
10077368320 bytes transferred in 1.162891 secs (8665788130 bytes/sec)

real    0m1.165s
user    0m0.003s
sys     0m1.162s

≈8.67 GB/秒

--

OS X's read of the boot drive optimal I/O block size (1TB SSD, HFS+):
Titanic:lb-bu admin$ stat -f %k /
4096

--

OS X's read of the array's optimal I/O block size (16-drives RAIDZ2, ZFS):
Titanic:lb-bu admin$ stat -f %k .
1024

--

また、ファイルシステムと並行してプール上に ZFS ボリュームを作成し、HFS+ としてフォーマットしました。上記と同じパフォーマンスが得られました。

最適値の 20 ～ 30 倍も低い速度で実行しています。何が足りないのでしょうか? 何かアイデアはありますか?

--

更新: 高速化はキャッシュされた I/O でした (@yoonix に感謝)。約 300MB/秒の速度は、このハードウェアにとってはまだ遅すぎるようです。

@qasdfdsaq: I/O 中の CPU 使用率はごくわずかです (すべてのコア <5%)。

zfs はすべての出力を取得します:

NAME            PROPERTY               VALUE                    SOURCE
lb-bu           type                   filesystem               -
lb-bu           creation               Tue Sep 30 16:41 2014    -
lb-bu           used                   36.8T                    -
lb-bu           available              10.0T                    -
lb-bu           referenced             138M                     -
lb-bu           compressratio          1.00x                    -
lb-bu           mounted                yes                      -
lb-bu           quota                  none                     default
lb-bu           reservation            none                     default
lb-bu           recordsize             128K                     default
lb-bu           mountpoint             /Volumes/lb-bu           local
lb-bu           sharenfs               off                      default
lb-bu           checksum               on                       default
lb-bu           compression            lz4                      local
lb-bu           atime                  on                       default
lb-bu           devices                on                       default
lb-bu           exec                   on                       default
lb-bu           setuid                 on                       default
lb-bu           readonly               off                      default
lb-bu           zoned                  off                      default
lb-bu           snapdir                hidden                   default
lb-bu           aclmode                discard                  default
lb-bu           aclinherit             restricted               default
lb-bu           canmount               on                       default
lb-bu           xattr                  on                       default
lb-bu           copies                 1                        default
lb-bu           version                5                        -
lb-bu           utf8only               on                       -
lb-bu           normalization          formD                    -
lb-bu           casesensitivity        insensitive              -
lb-bu           vscan                  off                      default
lb-bu           nbmand                 off                      default
lb-bu           sharesmb               off                      default
lb-bu           refquota               none                     default
lb-bu           refreservation         none                     default
lb-bu           primarycache           all                      default
lb-bu           secondarycache         all                      default
lb-bu           usedbysnapshots        0                        -
lb-bu           usedbydataset          138M                     -
lb-bu           usedbychildren         36.8T                    -
lb-bu           usedbyrefreservation   0                        -
lb-bu           logbias                latency                  default
lb-bu           dedup                  off                      default
lb-bu           mlslabel               none                     default
lb-bu           sync                   standard                 default
lb-bu           refcompressratio       1.01x                    -
lb-bu           written                138M                     -
lb-bu           logicalused            36.8T                    -
lb-bu           logicalreferenced      137M                     -
lb-bu           snapdev                hidden                   default
lb-bu           com.apple.browse       on                       default
lb-bu           com.apple.ignoreowner  off                      default
lb-bu           com.apple.mimic_hfs    off                      default
lb-bu           redundant_metadata     all                      default
lb-bu           overlay                off                      default

Answer 1

これについては投稿していませんzpool statusが、投稿では、16 個のディスクすべてが RAIDZ2 の単一の vdev にあると示唆しています。これは適切で安全な構成ですが、RAIDZ は主に速度のために設計されているわけではないことを理解する必要があります。RAIDZ はほぼ防弾になるように設計されています。RAIDZ2 は RAID6 に似ていますが、そのバリアントには、より低速でより安全な機能があります。

見るこの素晴らしい記事詳細については、次の 2 つの引用文を参照してください (強調は筆者による)。

RAID-Z vdev に書き込む場合、各ファイルシステム ブロックは、RAID-Z vdev のすべてのデバイス (潜在的に) にわたって独自のストライプに分割されます。つまり、各書き込み I/O は、RAID-Z vdev 内のすべてのディスクが書き込みを完了するまで待機する必要があります。したがって、IO の完了を待機している単一のアプリケーションの観点からは、RAID-Z vdev 内の最も遅いディスクの IOPS 書き込みパフォーマンスが得られます。

RAID-Z vdev から読み取る場合、プロセスは基本的に逆になるので、同じルールが適用されます (ミラーリングの場合のようなラウンドロビンのショートカットはありません)。運が良ければ帯域幅が向上します (書き込んだのと同じ方法で読み取れます)。そして、重要なケースのほとんどにおいて、単一ディスクのIOPS読み取りパフォーマンスは。

実際には、16 台の中速ドライブがあり、各書き込みパスごとに、16 台のドライブすべてがコントローラにチェックインして「完了」と通知されるまで待機してから、次の書き込みを開始します。16 台のディスクでは、実質的には常に、書き込みの 1 つを実行する前にディスクがほぼ完全に回転するのを待機することになるため、物理的性質と ZFS がデータをコミットする方法によって遅延が発生します。

一般的に、単一プロセス/スレッド書き込みタスクは ZFS にとって最適なケースではありません。複数の小さなデータ読み取り/書き込みタスクを同時に実行すると、より良い IOPS 数値が表示される可能性がありますが、ZFS の物理的性質が主な問題だと思います。

スペースを犠牲にしても構わないのであれば、ミラーリングの方が高速になる可能性があります。また、プールに 16 ディスクの RAIDZ2 vdev 1 つではなく 8 ディスクの RAIDZ2 vdev 2 つを作成することで、ZFS のパフォーマンスがわずかに向上する可能性もあります。この場合も使用可能なストレージ スペースは消費されますが、コミットが高速化する可能性があります。

残念ながら良いニュースはありません。