9x7ドライブraidz2（ZFS ZoL 0.8.1）のシーケンシャル速度が遅い

Ubuntu 18.04で、256K以上のリクエストサイズのシーケンシャルな読み取りと書き込み（バックアップ用）を介して構築された大きなZFSプールを実行しています。高いスループットとスペース効率の必要性、およびランダムな小ブロックパフォーマンスの必要性が少ないことを考慮して、ストライプミラーではなくストライプraidz2を使用しました。

ただし、256Kのシーケンシャルリードパフォーマンスは予想よりもはるかに低くなっています（100〜200MBps、ピークは最大600MBps）。zvolがiostatで最大99％のiowaitに達している場合、バッキングデバイスは通常10から40％のiowaitで動作します。これは、バックプレーンまたはCPUであってはならないので、ボトルネックが構成に欠けていることを示唆していますこのシステム、およびシーケンシャルワークロードは、ARCをあまり強く動作させるべきではありません。

私はモジュールパラメータ（以下の現在の構成）でかなり遊んだり、数百の記事を読んだり、OpenZFS githubの問題などを行ったりしました。プリフェッチと集約を調整すると、このパフォーマンスレベルになりました。デフォルトでは、約50MBpsで実行していました。 ZFSがディスクにTINYリクエストを送信していたため、シーケンシャルリード（約16K）。集約とプリフェッチは正常に機能していると思いますが（おそらく）、iostatのディスク読み取りは平均で約64Kです。

NICはLIO iscsiターゲットであり、cxgbitオフロード+ Windows Chelsio iscsiイニシエーターはZFS zvolsの外側で適切に機能し、直接マッピングされたオプタンがNICでほぼフルラインレートを返します（約3.5GBpsの読み取りと書き込み）。

期待しすぎですか？ZFSはパフォーマンスよりも安全性を優先することを知っていますが、7x9 raidz2が単一の9ドライブmdadm raid6よりも優れた順次読み取りを提供することを期待しています。

システムの仕様とログ/構成ファイル：

Chassis: Supermicro 6047R-E1R72L
HBAs: 3x 2308 IT mode (24x 6Gbps SAS channels to backplanes)
CPU: 2x E5-2667v2 (8 cores @ 3.3Ghz base each)
RAM: 128GB, 104GB dedicated to ARC
HDDs: 65x HGST 10TB HC510 SAS (9x 7-wide raidz2 + 2 spares)
SSDs: 2x Intel Optane 900P (partitioned for mirrored special and log vdevs)
NIC: Chelsio 40GBps (same as on initiator, both using hw offloaded iSCSI)
OS: Ubuntu 18.04 LTS (using latest non-HWE kernel that allows ZFS SIMD)
ZFS: 0.8.1 via PPA
Initiator: Chelsio iSCSI initiator on Windows Server 2019

プール構成：

ashift=12
recordsize=128K (blocks on zvols are 64K, below)
compression=lz4
xattr=sa
redundant_metadata=most
atime=off
primarycache=all

ZVol構成：

sparse
volblocksize=64K (matches OS allocation unit on top of iSCSI)

プールのレイアウト：

7x 9-wide raidz2
mirrored 200GB optane special vdev (SPA metadata allocation classes)
mirrored 50GB optane log vdev

/etc/modprobe.d/zfs.conf：

# 52 - 104GB ARC, this system does nothing else
options zfs zfs_arc_min=55834574848
options zfs zfs_arc_max=111669149696

# allow for more dirty async data
options zfs zfs_dirty_data_max_percent=25
options zfs zfs_dirty_data_max=34359738368

# txg timeout given we have plenty of Optane ZIL
options zfs zfs_txg_timeout=5

# tune prefetch (have played with this 1000x different ways, no major improvement except max_streams to 2048, which helped, I think)
options zfs zfs_prefetch_disable=0
options zfs zfetch_max_distance=134217728
options zfs zfetch_max_streams=2048
options zfs zfetch_min_sec_reap=3
options zfs zfs_arc_min_prefetch_ms=250
options zfs zfs_arc_min_prescient_prefetch_ms=250
options zfs zfetch_array_rd_sz=16777216

# tune coalescing (same-ish, increasing the read gap limit helped throughput in conjunction with low async read max_active, as it caused much bigger reads to be sent to the backing devices)
options zfs zfs_vdev_aggregation_limit=16777216
options zfs zfs_vdev_read_gap_limit=1048576
options zfs zfs_vdev_write_gap_limit=262144

# ZIO scheduler in priority order 
options zfs zfs_vdev_sync_read_min_active=1
options zfs zfs_vdev_sync_read_max_active=10
options zfs zfs_vdev_sync_write_min_active=1
options zfs zfs_vdev_sync_write_max_active=10
options zfs zfs_vdev_async_read_min_active=1
options zfs zfs_vdev_async_read_max_active=2
options zfs zfs_vdev_async_write_min_active=1
options zfs zfs_vdev_async_write_max_active=4

# zvol threads
options zfs zvol_threads=32

これで髪の毛をちぎりました。ユーザーからストレージスペースのあるすべてのWindowsに移行するというプレッシャーがかかっていますが、私はパリティーストレージスペースを使用しました（ミラーが上にあるストレージスペースダイレクトを使用している場合でも）。私はiSCSIの下でmdadm raid60にまっすぐに行きたくなりますが、ZFSのビットロート保護でパフォーマンスのロックを解除する、私が見逃している骨の折れる何かを誰かが指摘できるなら、それを気に入ってくれます:)

良い質問。

• スパースzvolブロックサイズは128kにする必要があると思います。
• ZIOスケジューラーの設定はすべて、最低10から最高64のように、もっと高くする必要があります。
• zfs_txg_timeoutはもっと長くなければなりません。私のシステムでは15秒または30秒です。
• 複数のRAIDZ3（またはタイプミス）はやり過ぎで、パフォーマンスに大きな影響を与えていると思います。RAIDZ2でベンチマークできますか？

編集：システムにNetdataをインストールし、使用率とZFS統計を監視します。

Edit2：これはVeeamリポジトリ用です。VeeamはLinuxをターゲットとしてサポートし、ZFSとうまく連携します。それをデータでベンチマークすることを検討しますか？NICのオフロードがソリューションの重要な部分でない限り、zvolsはあなたがやっていることの理想的なユースケースではありません。