基准结果
现在，我们将检查基准结果，以验证我们在上一单元中讨论的性能提示。 具体而言，我们专注于使用 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 |
| 支持的最低服务级别 | 标准 | 标准 |
| 观察到的最大吞吐量 | 4,500 MiB/s | 10,240 MiB/s |
| 观察到的最大读取 IOPS | ~200,000 | ~700,000 |
| 观察到的最大写入 IOPS | ~135,000 | ~474,000 |
常规卷的 SPEC EDA 工具的基准检验结果
本节中的图形演示 I/O 和延迟曲线。 他们研究以下性能实践的一些组合：
nocto,actimeo=600sysctl tunednconnect=16
当应用上述所有三种做法时，每秒的 I/O作都会增加，并且仍保持低延迟（小于 1 毫秒）。
下图演示了 NFSv3 对于这种类型的工作负荷，NFSv3 的性能优于 NFSv4.1。
下图演示了 rsize=wsize=262144(256 K) 性能优于其他设置。
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 |
与 Azure NetApp 文件中的常规卷相比，测试使用 SPEC SFS 基准比较了大型卷的性能功能。
| 情景 | 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 和吞吐量。
显示更高吞吐量的 F I O 结果的图表。
大型卷的 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/s)
该图表示 256 KiB 顺序工作负荷和 1 TiB 工作集。 它表明，单个 Azure NetApp 文件大型卷可以处理大约 8,518 MiB/s 的纯顺序写入和 9,970 MiB/s 纯顺序读取。
8-KiB 随机工作负荷 (IOPS)
该图表示 8-KiB 随机工作负荷和 1 TiB 工作集。 该图显示 Azure NetApp 文件大型卷的处理次数可在大约 474,000 次（纯随机写入）到大约 709,000 次（纯随机读取）之间。
