我对 ZFS 完全陌生，所以一开始我想我会对它做一些简单的基准测试，以了解它的行为方式。我想突破它的性能极限，所以我配置了一个 Amazon EC2i2.8xlarge实例（几乎 7 美元/小时，时间就是金钱！）。此实例有 8 个 800GB SSD。

我fio对 SSD 本身进行了测试，并得到以下输出（已修剪）：

$ sudo fio --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --direct=1 --filename=/dev/xvdb
[trimmed]
  write: io=67178MB, bw=229299KB/s, iops=57324, runt=300004msec
[trimmed]

57K IOPS 用于 4K 随机写入。可敬。

然后我创建了一个跨越所有 8 个的 ZFS 卷。起初我有一个raidz1包含所有 8 个 SSD 的 vdev，但我读到了这对性能不利的原因，所以我最终得到了四个mirrorvdev，如下所示：

$ sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi
$ sudo zpool list …

我正在对基于SuperMicro E300-8D的小型服务器盒进行基准测试。我已经安装了带有最新更新的最新 CentOS 7.5、64GB DDR4-2100 RAM 和三星 970 EVO 1TB NVMe SSD。操作系统安装在 USB 记忆棒上的内部 USB 端口中，因此除了在我的基准测试期间，SSD 完全没有使用。

受ScyllaDB使用的基准测试方法的启发，我的测试目标是找到此 SSD 的最佳并发级别。为此，我使用了diskplorer，它在内部用于fio探索并发与 IOPS 和延迟之间的关系。它会生成如下所示的方便图表。在所有情况下，我都使用 4K 随机读取工作负载。

问题是我得到的结果毫无意义。这是第一个结果：

生的 /dev/nvme0n1

$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

这是太棒了！三星自己的规格表声称读取 IOPS 为 500K，20 次并发读取时，我得到了近 600K。右边的轴是以纳秒为单位的读取延迟，红线是平均延迟，误差线是 5% 和 95% 的延迟。所以看起来这个 SSD 的理想并发级别是大约 20 次并发读取，产生极好的延迟 < 100us。

那只是原始SSD。我会将 XFS 放在上面，它针对异步 I/O 进行了优化，而且我确信它不会增加任何显着的开销......

使用新的 XFS 文件系统 /dev/nvme0n1

$ sudo mkfs.xfs /dev/nvme0n1
$ sudo mount /dev/nvme0n1 /mnt
$ sudo ./diskplorer.py --mountpoint=/mnt --filesize=256G 

什么！？这是 …