基准结果

  • 5 分钟

现在，我们检查基准结果，验证我们在上一单元中讨论的性能技巧。 具体来说，我们重点介绍如何使用 SPEC SFS 基准套件以生成模拟类似 EDA 生产的工作负载的多个线程。 此外，我们将展示 FIO 结果，以检查一些性能做法。

这两个基准工具的概览

SPEC SFS 套件是 EDA 的标准行业基准。 典型的 EDA 工作负载包括功能阶段和物理阶段。 功能阶段驱动大多数随机 I/O 和文件系统元数据操作。 物理阶段驱动大规模顺序读取和写入操作。

FIO 是一种 I/O 工具，它可以生成一致的随机或顺序读取/写入负载，以对存储目标的 IOPS 和吞吐量进行基准检验。

Azure NetApp 文件中的卷类型

Azure NetApp 文件提供了两种可配置用于云数据存储的卷：常规卷和大型卷。 下表重点介绍了这两种卷类型之间的一些主要差异。 选择适合工作负载的卷类型时，请使用此表作为指导。

限制 常规卷 大型卷
最小容量 100 GiB 50 TiB
最大容量 100 TiB 500 TiB
支持的最低服务级别 Standard Standard
观察到的最大吞吐量 4,500 MiB/s 10,240 MiB/秒
观察到的最大读取 IOPS ~200,000 ~700,000
观察到的最大写入 IOPS ~135,000 ~474,000

常规卷的 SPEC EDA 工具的基准检验结果

本部分中的图演示了 I/O 和延迟曲线。 它们检查以下性能做法的一些组合：

  • nocto,actimeo=600
  • sysctl tuned
  • nconnect=16

应用上述所有三种做法后，每秒 I/O 操作数会增加，同时仍保持较低的延迟（小于 1 毫秒）。

显示 SPEC EDA 结果的关系图，其中在应用所有三种做法时 I/O 增加仍可保持低延迟。

下图表明，对于此类工作负载，NFSv3 的性能优于 NFSv4.1。

显示 SPEC EDA 结果的示意图，表明 NFS 版本 3 的性能优于 NFS 版本 4.1。

下图表明，rsize=wsize=262144(256 K) 的性能优于其他设置。

显示用于比较 rsize 和 wsize 值的 SPEC EDA 结果的关系图。

大型卷的 SPEC EDA 工具的基准检验结果

使用 SPEC SFS 基准和以下配置对单个大型卷进行性能阈值测试：

配置类型 设置
操作系统 RHEL 9.3/RHEL 8.7
实例类型 D16s_v5
实例计数 10
装载选项 nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8

这些测试使用 SPEC SFS 基准对大型卷的性能与 Azure NetApp 文件中的常规卷进行了比较。

场景 I/O 速率（响应时间为 2 毫秒） MiB/秒（响应时间为 2 毫秒）
一个常规卷 39,601 692
一个大型卷 652,260 10,030

比较大型卷的延迟和吞吐量的关系图。

常规卷的 FIO 工具的基准检验结果

以下 FIO 命令分别对 IOPS 和吞吐量进行基准检验。

// FIO commands to benchmark IOPS:
// 8K Random Reads
fio --name=8krandomreads --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 8K Random Writes
fio --name=8krandomwrites --rw=randwrite --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting

// FIO commands to benchmark throughput:
// 64K Sequential Reads
fio --name=64kseqreads --rw=read --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 64K Sequential Writes
fio --name=64kseqwrites --rw=write --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting

以下两个图表明了在优化 nocto,actimeo=600、nconnect=16 和 sysctl 时，Azure NetApp 文件可以实现更高的 IOPS 和吞吐量。

显示具有更高 IOPS 的 FIO 结果的关系图。

显示具有更高吞吐量的 FIO 结果的关系图。

大型卷的 FIO 工具的基准检验结果

本部分介绍使用 FIO 基准的单个大型卷的性能阈值。 测试使用以下配置运行：

组件 配置
Azure VM 大小 E32s_v5
Azure VM 流出量带宽限制 2000MiB/秒（2GiB/秒）
操作系统 RHEL 8.4
大型卷大小 101 TiB“超高性能”（10,240 MiB/秒吞吐量）
装载选项 hard,rsize=65536,wsize=65536,vers=3
注意：使用 262144 和 65536 有类似的性能结果。

256-KiB 连续工作负载（MiB/秒）

该图表示 256 KiB 连续工作负载和 1 TiB 工作集。 它显示单个 Azure NetApp 文件大型卷的处理速度可在大约 8,518 MiB/秒（纯连续写入）到大约 9,970 MiB/秒（纯连续读取）之间。

大型卷上 256-KiB 连续工作负载的条形图。

8-KiB 随机工作负载 (IOPS)

该图表示 8-KiB 随机工作负载和 1 TiB 工作集。 该图显示 Azure NetApp 文件大型卷的处理次数可在大约 474,000 次（纯随机写入）到大约 709,000 次（纯随机读取）之间。

大型卷上随机工作负载的条形图。