fio在具有以下设置的新服务器上运行了几个测试：
- 1 个三星 PM981a 512GB M.2 NVMe 驱动器。
- Proxmox 在 root 上安装了 ZFS。
- 1x VM 创建了 30GB 空间并安装了 Debian 10。
- 6 个 Intel P4510 2TB U.2 NVMe 驱动器通过 OCuLink 连接到 6 个专用 PCIe 4.0 x4 通道。
- 直接连接到单个 VM。
- 在 VM 中配置为 RAID10（条带化 3 个镜像）。
- 主板/CPU/内存：华硕KRPA-U16/EPYC 7302P/8x32GB DDR4-3200
这些磁盘的顺序读取速度高达 3,200 MB/s 。从理论上讲，最大带宽应为 19.2 GB/s。
在 ZFS RAID 上运行我得到的结果在 ~2,000 - 3,000 MB/s 范围内（例如，在运行 Crystal Disk Mark 时，在没有 ZFS 或任何其他开销的情况下进行测试时，磁盘能够达到 3,200 MB/ fiosnumjobs=1在直接安装在其中一个磁盘上的 Windows 中）：
fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=1 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
READ: bw=2939MiB/s (3082MB/s), 2939MiB/s-2939MiB/s (3082MB/s-3082MB/s), io=100GiB (107GB), run=34840-34840msec
考虑到一切似乎都是合理的。也可能受 CPU 限制，因为其中一个内核将处于 100% 负载（其中一些用于 ZFS 进程）。
当我增加到numjobs8-10 时，事情变得有点奇怪：
fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=10 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
READ: bw=35.5GiB/s (38.1GB/s), 3631MiB/s-3631MiB/s (3808MB/s-3808MB/s), io=1000GiB (1074GB), run=28198-28199msec
38.1 GB/s - 远高于理论最大带宽。
这里的解释究竟是什么？
评论补充：
虚拟机配置：
iotop测试期间：
第一个
fio（带有 的--numjobs=1）顺序执行任何读取操作，除了快速预读/预取之外，您的条带配置没有任何好处：iodepth仅适用于通过libaio引擎完成的异步读取，这反过来需要真正的支持O_DIRECT（ZFS 缺乏） . 您可以尝试将预取窗口从默认的 8M 增加到 64M (echo 67108864 > /sys/module/zfs/parameters/zfetch_max_distance)。当然，您的里程可能会有所不同，因此请务必检查这不会影响其他工作负载。第二个
fio（带有 的那个--numjobs=8）可能被 ARC 缓存扭曲了。可以肯定的是，只需打开另一个运行的终端dstat -d -f：您将看到每个磁盘的真实传输速度，它肯定会与它们的理论最大传输速率一致。您还可以fio使用新启动的机器（因此使用空 ARC）重试测试，以查看情况是否发生变化。对于具有多个作业的顺序 I/O 测试，每个作业（即线程）都有一个特定于线程的文件指针（原始设备的块地址），默认情况下从零开始，并且独立于其他线程前进。这意味着 fio 将使用跨作业的重复/重叠文件指针/块地址向文件系统发出读取请求。
write_iolog如果您使用该选项，您可以看到这一点。重叠的请求会使基准测试结果出现偏差，因为它们可能会被文件系统中的读取缓存（在测试文件时）或设备（在原始卷上运行时）满足。相反，您想要的是单个作业，然后
iodepth专门修改参数以控制 I/O 队列深度。这指定了每个作业允许活动的并发 I/O 数量。唯一的缺点是总可实现的 IOP 可能会受到单核/线程限制。对于大块顺序工作负载，这应该不是问题，因为它们不受 IOP 限制。对于随机 I/O，您肯定希望使用多个作业，尤其是在可以处理超过一百万 IOP 的 NVMe 驱动器上。