☰

FIO 基准测试 - 不一致且比预期慢：我的 RAID 配置错误吗？

tag-icon • tag-icon raid storage zfs proxmox dell-perc
FIO 基准测试 - 不一致且比预期慢：我的 RAID 配置错误吗？

总结：我的虚拟机管理程序存储出现了一些性能问题。以下是来自的一系列测试结果fio。跳至相关Results部分阅读相关内容并查看我的问题。

概括

我最近购买了一台 R730xd，因此在迁移到它之前，我想确保存储性能最佳。我一直在运行一些基准测试菲奥并发现了一些令人震惊的结果。结合这些结果和图表，我收集了相当多的图表来展示我的各个存储后端存在的问题。

然而，我很难把它变成可用的信息因为我没有任何东西可以与之比较。我认为我遇到了一些非常奇怪的性能问题。

磁盘配置

以下是向我的虚拟机管理程序（Proxmox）公开的四种存储类型：

╔═══════════╦════════════════════════════════╦═════════════╦════════════════════════════╗
║  Storage  ║            Hardware            ║ Filesystem  ║        Description         ║
╠═══════════╬════════════════════════════════╬═════════════╬════════════════════════════╣
║ SATADOM   ║ 1x Dell K9R5M SATADOM          ║ LVM/XFS     ║ Hypervisor filesystem      ║
║ FlashPool ║ 2x Samsung 970 EVO M.2 SSD     ║ ZFS RAID 1  ║ Hypervisor Compute Storage ║
║ DataPool  ║ 6x HGST 7200RPM HDD            ║ ZFS RAID 10 ║ Redundant Data Storage     ║
║ RAIDPool  ║ 6x Seagate/Hitachi 7200RPM HDD ║ HW RAID 10  ║ General Purpose Storage    ║
╚═══════════╩════════════════════════════════╩═════════════╩════════════════════════════╝

存储详细信息

以下是每个存储后端的详细分类：

  1. SATA 硬盘：SATADOM由 Proxmox 通过 LVM 直接管理。这里是 的输出lvdisplay pve。SATADOM 通过内部 DVD-ROM SATA 端口连接到服务器，因为该端口在R730xd模型中未使用。

  2. 闪存池：这FlashPool是一个由双 NVMe SSD 组成的简单 ZFS RAID 1。目标是将其用作我的虚拟机的后备存储。这里是以下的输出：

     zpool list  
 zpool status  
 zfs get all

    每个 SSD 都FlashPool通过以下方式连接到服务器PCI-E -> M.2 适配器安装在 x16 PCIe 插槽中。我知道这些是 x4 PCIe 适配器。但是，我很确定 NVMe 只能以该速度运行，因此不会制造更快的适配器。

  3. 数据池：这DataPool是唯一预先存在的数据集。它已有几年历史，以前用于数据和虚拟机存储，但性能不佳。它还由 Proxmox 作为 ZFS RAID 10 进行管理。

    它最初由磁盘组成6x 4TB HGST Ultrastar 7K4000 7200RPM。然而，随着它们开始出现故障，我决定用更高密度的磁盘替换它们。因此，该阵列现在由以下部分组成：

     2x 6TB HGST Ultrastar He6 7200RPM  
 4x 4TB HGST Ultrastar 7K4000 7200RPM

    由于旧磁盘不断出现故障，我显然打算最终完全转向 6TB 磁盘。这里是针对上面发布的相同命令的输出FlashPool。

    这 6 个磁盘通过背板上的前 6 个托架连接到服务器。此背板连接到 Dell H730 Mini PERC RAID 控制器。

  4. 磁盘阵列池：这RAIDPool是一个实验性的存储后端。我以前从未使用过硬件 RAID，所以我很高兴现在我有一个合适的 RAID 控制器。与类似DataPool，这些磁盘安装在背板的最后 6 个托架中。但是，它们不是通过 Proxmox，而是由 PERC 管理。它们作为单个磁盘呈现给 Proxmox，然后由 LVM 管理并通过逻辑卷作为 XFS 文件系统呈现给操作系统。这里是 的输出lvdisplay RAIDPool。

RAID 控制器配置

因此，您可能刚刚注意到，和DataPool均由RAIDPoolH730 RAID 控制器安装和管理。但是，DataPool由 Proxmox 通过 ZFS 管理，而RAIDPool由实际控制器管理。

这里这是物理磁盘拓扑的屏幕截图。H730 能够将磁盘直接传递到操作系统，同时管理其他磁盘。如您所见，前 6 个磁盘配置为Non-RAID模式，后 6 个磁盘配置为Online模式。

  • 这里是 iDRAC UI 中控制器的配置属性。
  • 虚拟磁盘 ( ) 上的磁盘缓存已启用回写和预读RAIDPool。由于这是专门为 VD 配置的，因此它不会影响 ZFS 驱动器。
  • 非 RAID 的 Dick Cache磁盘（ZFS DataPool）设置为Disable。
  • 这链接速度所有驱动器的设置为auto。

此外，在再次检查所有设置后，我启用了Write Cache嵌入式 SATA 控制器。因此，从SATADOM下面的基准测试中可以看出，这可能会提高性能。

基准测试：

我用两种方式对所有这些存储后端进行了基准测试。在这两种测试中，我都fio-plot在小脚本将结果转储到几个文件夹中。

如果你疯了，想自己分析原始结果，他们来了。您需要稍微调整一下我的脚本才能重新运行，因为我在上传之前移动了目录结构来组织它。

简而言之，他们对每个存储后端进行了一系列测试，以评估其随机的带宽、IOPS 和延迟。然后，它会将这些结果绘制在图表上。有些图表比较了多个后端。其他图表仅显示单个后端的结果。我没有执行任何顺序测试。在所有情况下，都使用默认块大小进行测试。

测试1）在 Proxmox 中，我将所有存储后端都安装到/mnt目录中。ZFS 池只是导入到操作系统中，RAIDPool 和都SATADOM通过 LVM 呈现给操作系统。每个都有一个格式化为 XFS 分区的逻辑卷，用于基准测试。注意：我从实时操作系统运行这些基准测试，因此性能SATADOM会受到相应影响。

日志文件是使用以下命令生成的：

./bench_fio --target /mnt/SATADOM_Data/bm --type directory --size 450M --mode randread randwrite --output SATADOM
./bench_fio --target /mnt/RAIDPool_Data/bm --type directory --size 1G --mode randread randwrite --output RAIDPOOL
./bench_fio --target /mnt/DataPool/bm/ --type directory --size 1G --mode randread randwrite --output DATAPOOL
./bench_fio --target /mnt/FlashPool/bm/ --type directory --size 1G --mode randread randwrite --output FLASHPOOL

测试2）我在 Proxmox 中创建了三台虚拟机。每台虚拟机都使用了来自、和的不同后备存储FlashPool。DataPool和RAIDPoolDataPoolFlashPool虚拟机在自己的 ZFS 数据集中运行。RAIDPool虚拟机在其自己的厚配置逻辑卷上运行。所有三台虚拟机都配备了 4 个 vCPU 和 40GB 内存。

日志文件是使用以下命令生成的：

./bench_fio     --target /fio     --type file     --size 1G     --mode randread randwrite     --duration 600     --output DATAPOOL_VM
./bench_fio     --target /fio     --type file     --size 1G     --mode randread randwrite     --duration 600     --output RAIDPOOL_VM
./bench_fio     --target /fio     --type file     --size 1G     --mode randread randwrite     --duration 600     --output FLASHPOOL_VM

结果：

上述 Imgur 链接中的图表应该都按相同的顺序排列。两个基准测试的结果有很大不同。但当你考虑到虚拟化的开销时，这是可以预料到的。我没想到的是，它们的表现似乎都差不多。

  • 例如，这张图表显示，当fio从虚拟机内部运行时，平均写入带宽约为 125 MB/s。RAID 1 中的两个 NVMe SSD（FlashPool）难道不应该大大优于 吗SATADOM？相反，您可以看到FlashPool虚拟机花费了最长的时间来完成测试，并且平均写入带宽最慢。对于写入 IOPS比较——平均 IOPS 约为 3,000，并且FlashPoolVM 执行测试所花的时间最长！

  • 抛开在虚拟机内部进行的基准测试，转而查看通过直接与虚拟机管理程序中的存储交互进行的基准测试，我们可以看到一些不同的行为。例如，在这个测试中FlashPool和的写入带宽DataPool高达 400MB/s。然而， 的RAIDPool平均性能约为 10MB/s。巧合的是，这与 大致相同SATADOM？ 当然， 的性能RAIDPool应该与 兼容，甚至更好DataPool？ 鉴于它们由同一 RAID 控制器中存在的类似磁盘组成？ 与上述类似，写入 IOPS展现同样离奇的故事。

  • 写入延迟Hypervisor 测试的结果似乎也不太正常。似乎RAIDPool比 ZFS Pools 的延迟高出十倍？但是，如果你翻到VM 测试，三个存储后端的延迟似乎集中在 300us 左右。这与我们在 的最差结果中看到的情况非常相似RAIDPool。为什么在从虚拟机而不是虚拟机管理程序运行测试时，写入延迟会发生这种平滑的影响？为什么 ZFS 池的延迟突然变得更糟，并且与 相当RAIDPool？

  • 查看读取带宽、IOPS 和延迟，结果类似。尽管硬件配置有很大差异，但在虚拟机中进行基准测试时，所有指标都同样缓慢。但是，一旦从虚拟机管理程序进行基准测试，ZFS 池突然就大大优于其他所有池？

问题：

  1. 这些结果不正常...对吧？这基准这网站显示 970 EVO 可实现高达 900MB/s 的随机写入速度。为什么我的只有虚拟机管理程序上为 150MB/s和虚拟机中为 10MB/s? 为什么从虚拟机管理程序和 VM 进行基准测试时这些速度会有如此大的差异？

  2. 为什么RAIDPool从 Hypervisor 进行基准测试时突然变得异常缓慢？这里我们看到虚拟机中的读取带宽平均为 20MB/s。但是，从虚拟机管理程序，它反而报告 4MB/s。就像我在问题 1 中展示的基准测试一样，这些读取速度难道不应该更接近900MB/秒？

  3. 为什么在虚拟机中而不是虚拟机管理程序中进行基准测试时，ZFS 池的性能突然显著下降？例如，这里我们可以看到读取 IOPS 平均约为 200,000，延迟低于 650us。然而，当从在虚拟机中，我们突然发现读取 IOPS 平均值约为 2,500，而延迟增加了四倍多？两种情况下的性能不应该大致相同吗？

答案1

在对 ZFS 池进行基准测试时，您需要了解缓存和记录大小如何与您的工作负载交互：

  • 您的fio命令不会跳过 linux 页面缓存（无--direct=1选项），也不会跳过 ZFS ARC。但是，由于两者之间的操作模式不同，您可能最终会倾向于使用普通文件系统 (XFS) 而不是 ZFS，反之亦然。为了减轻缓存效应，我建议您使用比 RAM 值大 2 倍的文件进行基准测试（即：如果有 24 GB 的 RAM，请使用 48 GB 的文件）。不是禁用缓存的 ZFS 基准测试（即primarycache=none：），作为 CoW 文件系统需求高缓存命中率可提供良好的性能（特别是在写入小于记录大小的块时，如下所示）；

  • 您的随机读/写 IOP 和吞吐量将受到 ZFSrecordsize属性的严重影响，因为 ZFS 通常会传输完整的记录大小块（小文件除外，其中“小”表示 < 记录大小）。换句话说，在fio读取/写入 4K 块时，ZFS 实际上读取/写入 32K 块对于每个 4K 块请求fio。缓存可以（并且会）改变这个通用规则，但要点仍然存在：对于较大的记录大小，吞吐量饱和可能是一个问题。请注意，我是不是指出 32K 记录大小是不合理的（尽管我可能会使用 16K 来限制 SSD 的磨损）；但是，在评估基准测试结果时需要考虑到这一点；

  • 我将重新启用直通磁盘的物理磁盘缓存，因为 ZFS 知道如何刷新其易失性缓存。但是，您需要检查您的 H730P 是否遵守直通磁盘的 ATA FLUSHes/FUA（它应该通过同步，但它的手册对这一点不清楚，而且我也没有实际的硬件可以尝试）；

  • 您的RAIDPool阵列由机械硬盘组成，因此其随机读取性能将会很低（控制器缓存不会帮助您进行随机读取）。

综合考虑，我认为您的结果并不异常；相反，它们不代表有效的工作负载，并且部分被误解了。如果您真的想比较 ZFS 和 HWRAID+XFS，我建议您使用实际预期的工作负载（即：数据库 + 应用程序虚拟机执行一些有用的工作）进行测试，同时确保使用ThinLVM（而不是传统的 LVM）至少具有快速快照功能，有点类似于 ZFS 自己的快照/克隆功能。

但是，从某种意义上说，你可以避免做这些测试，因为结果是相当可预测的：

  • 简单的 HWRAID+LVM+XFS 设置对于适合 Linux 页面缓存的数据集的顺序 IO 和随机读/写速度会更快：不受 CoW 的影响，它的开销比 ZFS 小得多；

  • 在实际场景中，ZFS 设置会更快，因为 ARC 的抗扫描特性将确保最常用的数据始终保持缓存。此外，压缩和校验和是两个杀手级功能（要获得 HWRAID 的类似功能，您需要使用堆叠dm-integrity+ vdo+thinlvm设置，这本身会造成很大的性能损失）。

作为参考，我最近将配备 H710P + 12 个 10K RPM SAS 磁盘的 Dell R720xd 替换为更便宜的 SuperMicro 5029WTR，配备 2 个 SSD（用于启动和 L2ARC）+ 1 个 NVMe Optane（用于 SLOG）和 6 个 7.2K RPM SATA 磁盘。SuperMicro 系统的标称随机读取性能仅为 Dell 系统的 1/3，但由于 ARC/L2ARC 和压缩，其性能要好得多。

最后，虽然我完全理解使用传统 HWRAID+LVM+XFS 系统的动机，但我不会再使用它而不是将 ZFS 作为裸机的虚拟机管理程序（除非针对特定的工作负载，这些工作负载在使用 CoW 层时性能真的很差，或者需要极快的速度和 DirectIO - 请参阅 XFSdax选项）。

相关内容