![FIO 基准测试 - 不一致且比预期慢:我的 RAID 配置错误吗?](https://linux22.com/image/753677/FIO%20%E5%9F%BA%E5%87%86%E6%B5%8B%E8%AF%95%20-%20%E4%B8%8D%E4%B8%80%E8%87%B4%E4%B8%94%E6%AF%94%E9%A2%84%E6%9C%9F%E6%85%A2%EF%BC%9A%E6%88%91%E7%9A%84%20RAID%20%E9%85%8D%E7%BD%AE%E9%94%99%E8%AF%AF%E5%90%97%EF%BC%9F.png)
总结:我的虚拟机管理程序存储出现了一些性能问题。以下是来自的一系列测试结果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 ║
╚═══════════╩════════════════════════════════╩═════════════╩════════════════════════════╝
存储详细信息
以下是每个存储后端的详细分类:
SATA 硬盘:
SATADOM
由 Proxmox 通过 LVM 直接管理。这里是 的输出lvdisplay pve
。SATADOM 通过内部 DVD-ROM SATA 端口连接到服务器,因为该端口在R730xd
模型中未使用。闪存池:这
FlashPool
是一个由双 NVMe SSD 组成的简单 ZFS RAID 1。目标是将其用作我的虚拟机的后备存储。这里是以下的输出:zpool list zpool status zfs get all
每个 SSD 都
FlashPool
通过以下方式连接到服务器PCI-E -> M.2 适配器安装在 x16 PCIe 插槽中。我知道这些是 x4 PCIe 适配器。但是,我很确定 NVMe 只能以该速度运行,因此不会制造更快的适配器。数据池:这
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 控制器。
磁盘阵列池:这
RAIDPool
是一个实验性的存储后端。我以前从未使用过硬件 RAID,所以我很高兴现在我有一个合适的 RAID 控制器。与类似DataPool
,这些磁盘安装在背板的最后 6 个托架中。但是,它们不是通过 Proxmox,而是由 PERC 管理。它们作为单个磁盘呈现给 Proxmox,然后由 LVM 管理并通过逻辑卷作为 XFS 文件系统呈现给操作系统。这里是 的输出lvdisplay RAIDPool
。
RAID 控制器配置
因此,您可能刚刚注意到,和DataPool
均由RAIDPool
H730 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
和RAIDPool
DataPoolFlashPool
虚拟机在自己的 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,并且FlashPool
VM 执行测试所花的时间最长!抛开在虚拟机内部进行的基准测试,转而查看通过直接与虚拟机管理程序中的存储交互进行的基准测试,我们可以看到一些不同的行为。例如,在这个测试中
FlashPool
和的写入带宽DataPool
高达 400MB/s。然而, 的RAIDPool
平均性能约为 10MB/s。巧合的是,这与 大致相同SATADOM
? 当然, 的性能RAIDPool
应该与 兼容,甚至更好DataPool
? 鉴于它们由同一 RAID 控制器中存在的类似磁盘组成? 与上述类似,写入 IOPS展现同样离奇的故事。写入延迟Hypervisor 测试的结果似乎也不太正常。似乎
RAIDPool
比 ZFS Pools 的延迟高出十倍?但是,如果你翻到VM 测试,三个存储后端的延迟似乎集中在 300us 左右。这与我们在 的最差结果中看到的情况非常相似RAIDPool
。为什么在从虚拟机而不是虚拟机管理程序运行测试时,写入延迟会发生这种平滑的影响?为什么 ZFS 池的延迟突然变得更糟,并且与 相当RAIDPool
?查看读取带宽、IOPS 和延迟,结果类似。尽管硬件配置有很大差异,但在虚拟机中进行基准测试时,所有指标都同样缓慢。但是,一旦从虚拟机管理程序进行基准测试,ZFS 池突然就大大优于其他所有池?
问题:
这些结果不正常...对吧?这基准这网站显示 970 EVO 可实现高达 900MB/s 的随机写入速度。为什么我的只有虚拟机管理程序上为 150MB/s和虚拟机中为 10MB/s? 为什么从虚拟机管理程序和 VM 进行基准测试时这些速度会有如此大的差异?
为什么
RAIDPool
从 Hypervisor 进行基准测试时突然变得异常缓慢?这里我们看到虚拟机中的读取带宽平均为 20MB/s。但是,从虚拟机管理程序,它反而报告 4MB/s。就像我在问题 1 中展示的基准测试一样,这些读取速度难道不应该更接近900MB/秒?为什么在虚拟机中而不是虚拟机管理程序中进行基准测试时,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 和吞吐量将受到 ZFS
recordsize
属性的严重影响,因为 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
选项)。