9x7驱动器raidz2（ZFS ZoL 0.8.1）上的慢速顺序速度

我正在运行一个大型ZFS池，该池针对256K +请求大小的序列化读写，通过Ubuntu（04.04）上的iSCSI（用于备份）进行。考虑到对高吞吐量和空间效率的需求，以及对随机小块性能的需求减少，我选择了条带化raidz2而不是条带化镜像。

但是，256K顺序读取性能远远低于我的预期（100-200MBps，峰值高达600MBps）。当zvol在iostat中的iowait达到约99％时，后备设备的iowait通常在10％到40％的iowait之间运行，这对我来说是瓶颈，在配置中我缺少这个东西，因为它不应该是背板或CPU此系统以及顺序的工作负载不应使ARC太费劲。

我已经使用了很多模块参数（下面的当前配置），阅读了数百篇文章，有关OpenZFS github的问题，等等。调整预取和聚合使我达到了这种性能水平-默认情况下，我的运行速度约为50MBps ZFS向磁盘发送TINY请求时（约16K），顺序读取。通过聚合和预取工作正常（我认为），磁盘读取会更高，在iostat中平均约为64K。

NIC是具有cxgbit卸载功能的LIO iscsi目标+ Windows Chelsio iscsi启动器在ZFS zvols之外可以很好地工作，通过直接映射的optane返回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，但是我使用了奇偶校验存储空间（即使使用顶部带有镜像的Storage Spaces Direct），也不是很理想。我很想直接在iSCSI下使用mdadm raid60，但是如果有人指出我缺少的东西可以通过ZFS的bitrot保护来释放性能，我会喜欢的。

好问题。

• 我认为您的稀疏zvol块大小应为128k。
• 您的ZIO调度程序设置都应该更高，例如最小值10和最大值64。
• zfs_txg_timeout应该更长。我在系统上执行15或30s。
• 我认为多个RAIDZ3（或者说是一个错字）过大并且在性能中起了很大的作用。您可以使用RAIDZ2进行基准测试吗？

编辑：在系统上安装Netdata并监视利用率和ZFS统计信息。

Edit2：这是针对Veeam存储库的。Veeam支持将Linux作为目标，并且可以与ZFS完美配合。您是否考虑使用数据进行基准测试？zvols并不是您正在执行的理想用例，除非NIC的卸载是解决方案的关键部分。