你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

适用于 Linux 的 Azure NetApp 文件常规卷性能基准

本文介绍 Azure NetApp 文件为具有常规卷的 Linux 提供的性能基准。

整个文件流式处理工作负载（横向扩展基准测试）

横向扩展测试的目的是显示在横向扩展（或增加）同时向同一卷生成工作负载的客户端数量时，Azure NetApp 文件卷的性能。 这些测试通常能够将卷推到其性能极限的边缘，并对媒体渲染、AI/ML 等工作负载以及其他利用大型计算场执行工作的工作负载具有指示作用。

高 I/OP 横向扩展基准配置

这些基准使用了以下内容：

• 单个 Azure NetApp 文件 100 TiB 常规卷，包含 1 TiB 的数据集，使用超高性能层
• FIO（设置和不设置 randrepeat=0）
• 4 KiB 和 8 KiB 块大小
• 6 个运行 RHEL 9.3 的 D32s_v5 虚拟机
• NFSv3
• 手动 QoS
• 装载选项：rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

高吞吐量横向扩展基准配置

这些基准使用了以下内容：

• 单个 Azure NetApp 文件常规卷，包含 1 TiB 的数据集，使用超高性能层 FIO（设置和不设置 randrepeat=0）
• FIO（设置和不设置 randrepeat=0）
• 64 KiB 和 256 KiB 块大小
• 6 个运行 RHEL 9.3 的 D32s_v5 虚拟机
• NFSv3
• 手动 QoS
• 装载选项：rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

并行网络连接 (nconnect) 基准配置

这些基准使用了以下内容：

• 单个 Azure NetApp 文件常规卷，包含 1 TiB 的数据集，使用超高性能层
• FIO（设置和不设置 randrepeat=0）
• 4 KiB 和 64 KiB wsize/rsize
• 运行 RHEL 9.3 的单个 D32s_v4 虚拟机
• 使用和不使用 nconnect 的 NFSv3
• 装载选项：rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

纵向扩展基准测试

纵向扩展测试的目的是显示在纵向扩展（或增加）单个客户端上跨多个 TCP 连接同时向同一卷生成工作负载的作业数量（例如使用 nconnect）时，Azure NetApp 文件卷的性能。

如果没有 nconnect ，这些工作负载就无法突破卷的最大性能极限，因为客户端无法生成足够的 IO 或网络吞吐量。 这些测试通常反映单个用户在媒体渲染、数据库、AI/ML 和一般文件共享等工作负载中的体验。

高 I/OP 横向扩展基准

以下基准测试显示了使用以下各项时，Azure NetApp 文件在高 I/OP 工作负载下实现的性能：

• 32 个客户端
• 4 KiB 和 8 KiB 随机读取和写入
• 1 TiB 数据集
• 读/写比例如下：100%:0%、90%:10%、80%:20%，依此类推
• 涉及和不涉及文件系统缓存（在 FIO 中使用 randrepeat=0）

有关详细信息，请参阅测试方法。

结果：4 KiB、随机、包含客户端缓存

在此基准中，FIO 运行时没有使用 randrepeat 选项来随机化数据。 因此，发挥作用的缓存数量不定。 与不使用缓存、使用整个 IO 堆栈运行的测试相比，这种配置的整体性能略好。

在下图中，测试表明，Azure NetApp 文件常规卷在此基准测试期间可以处理约 130,000 次纯随机 4 KiB 写入和约 460,000 次纯随机 4 KiB 读取。 每次运行的工作负载读写混合比例调整 10%。

随着 I/OP 读写混合比例中的写入比例提高，总 I/OPS 会降低。

结果：4 KiB、随机、不包含客户端缓存

在此基准测试中，FIO 运行时采用 randrepeat=0 设置来随机化数据，从而减少缓存对性能的影响。 这导致写入 I/OPS 降低了约 8%，读取 I/OPS 降低了约 17%，但显示的性能数字更能代表存储设备的实际性能。

在下图中，测试表明，Azure NetApp 文件常规卷可以处理约 120,000 次纯随机 4 KiB 写入和约 388,000 次纯随机 4 KiB 读取。 每次运行的工作负载读写混合比例调整 25%。

随着 I/OP 读写混合比例中的写入比例提高，总 I/OPS 会降低。

结果：8 KiB、随机、不包含客户端缓存

由于每次操作都能发送更多数据，因此读写大小越大，总 I/OPS 就越少。 为了更准确地模拟大多数现代应用程序使用的读写大小，我们使用了 8 KiB 的读写大小。 例如，许多 EDA 应用程序都使用 8 KiB 的读写。

在此基准测试中，FIO 运行时使用 randrepeat=0 来随机化数据，从而降低客户端缓存影响。 在下图中，测试表明，Azure NetApp 文件常规卷可以处理约 111,000 次纯随机 8 KiB 写入和约 293,000 次纯随机 8 KiB 读取。 每次运行的工作负载读写混合比例调整 25%。

随着 I/OP 读写混合比例中的写入比例提高，总 I/OPS 会降低。

并排比较

为了说明缓存如何影响性能基准测试，下图显示了有和没有缓存机制的 4 KiB 测试的总 I/OPS。 如图所示，缓存为 I/OPS 带来了轻微的性能提升，趋势相当一致。

特定偏移、流式处理随机读/写工作负载：使用并行网络连接 (nconnect) 进行纵向扩展测试

以下测试显示了使用具有 4 KiB 随机工作负载和 1 TiB 数据集的单个客户端的高 I/OP 基准。 生成的工作负载组合每次使用不同的 I/O 深度。 为了提升单个客户端工作负载的性能，使用了 nconnect 装载选项，与不使用 nconnect 装载选项相比，这提高了并行度。

当使用标准 TCP 连接（仅提供一个通向存储的路径）时，每秒发送的总操作数比装载能够利用每个装入点的更多 TCP 连接（例如使用 nconnect）时要少。 当使用 nconnect 时，操作的总延迟通常较低。 运行这些测试时也设置了 randrepeat=0，以有意避免缓存。 有关此选项的详细信息，请参阅测试方法。

结果：4 KiB、随机、使用和不使用 nconnect、不包括缓存

下图并排比较了使用和不使用 nconnect 时的 4 KiB 读写情况，以突出显示使用 nconnect 时的性能改进：整体 I/OPS 更高、延迟更低。

高吞吐量基准

以下基准测试显示了 Azure NetApp 文件在高吞吐量工作负载下实现的性能。

高吞吐量工作负载本质上更具顺序性，通常读写量大，元数据少。 吞吐量通常比 I/OPS 更重要。 这些工作负载通常利用较大的读/写大小（64 K 到 256 K），与较小的读/写大小相比，会产生较高的延迟，因为较大的有效负载自然需要更长的时间来处理。

高吞吐量工作负载示例包括：

• 媒体存储库
• 高性能计算
• AI/ML/LLP

以下测试显示使用 64 KiB 和 256 KiB 顺序工作负载以及 1 TiB 数据集的高吞吐量基准测试。 生成的工作负载组合每次减少一定百分比，并展示了使用不同的读/写比率（例如，100%:0%、90%:10%、80%:20%，依此类推）时的预期结果。

结果：64 KiB 顺序 I/O、包括缓存

在此基准测试中，FIO 使用对填充缓存较为积极的循环逻辑运行，因此不确定的缓存量影响了结果。 与不使用缓存运行的测试相比，此结果的整体性能略好。

在下图中，测试表明 Azure NetApp 文件常规卷可处理约 4,500 MiB/s 的纯顺序 64 KiB 读取和约 1,600 MiB/s 的纯顺序 64 KiB 写入。 每次运行的工作负载读写混合比例调整 10%。

结果：64 KiB 顺序 I/O、不包括缓存

在这个基准测试中，FIO 使用对缓存填充不太积极的循环逻辑运行。 客户端缓存不会影响结果。 与不使用缓存的测试相比，此配置的写入性能略好，但读取性能较低。

在下图中，测试表明 Azure NetApp 文件常规卷可处理约 3,600 MiB/s 的纯顺序 64 KiB 读取和约 2,400 MiB/s 的纯顺序 64 KiB 写入。 在测试期间，采用 50/50 的混合比例时，总吞吐量与纯顺序读取工作负载相当。

每次运行的工作负载读写混合比例调整 25%。

结果：256 KiB 顺序 I/O、不包含缓存

在这个基准测试中，FIO 使用对缓存填充不太积极的循环逻辑运行，因此缓存不会影响结果。 此配置的写入性能略低于 64 KiB 测试，但读取性能高于不使用缓存运行的相同 64 KiB 测试。

在下图中，测试表明 Azure NetApp 文件常规卷可处理约 3,500 MiB/s 的纯顺序 256 KiB 读取和约 2,500 MiB/s 的纯顺序 256 KiB 写入。 在测试期间，采用 50/50 的混合比例时，总吞吐量峰值高于纯顺序读取工作负载。

每次运行的工作负载读写混合比例增加 25%。

并排比较

为了更好地展示缓存如何影响性能基准测试，下图显示了有和没有缓存机制的 64 KiB 测试的总 MiB/s。 由于缓存对读取性能的提升通常大于对写入性能的提升，因此缓存对总 MiB/s 的性能提升最初是微弱的。 随着读/写混合比例的变化，不使用缓存的总吞吐量会超过使用客户端缓存的结果。

并行网络连接 (nconnect)

以下测试显示了使用具有 64 KiB 随机工作负载和 1 TiB 数据集的单个客户端的高 I/OP 基准。 生成的工作负载组合每次使用不同的 I/O 深度。 为了提升单个客户端工作负载的性能，使用了 nconnect 装载选项，与不使用 nconnect 装载选项相比，这提高了并行度。 这些测试仅在不包含缓存的情况下运行。

结果：64 KiB、顺序、不包含缓存，使用和不使用 nconnect

以下结果显示了在使用和不使用操作并行化 (nconnect) 的情况下，在单个客户端上以 4 KiB 的区块对 NFSv3 装载进行读写时的纵向扩展测试结果。 图形显示，随着 I/O 深度的增加，I/OPS 也会增加。 但是，当使用标准 TCP 连接（仅提供一个通向存储的路径）时，每秒发送的总操作数比装载能够利用每个装入点的更多 TCP 连接时要少。 此外，使用 nconnect 时，操作的总延迟通常较低。

并排比较（使用和不使用 nconnect）

下图并排比较了使用和不使用 nconnect 时的 64 KiB 顺序读写情况，以突出显示使用 nconnect 时的性能改进：整体吞吐量更高、延迟更低。

详细信息

• 测试方法