你当前正在访问 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、读取与写入、基线（不包括缓存）
在此基线基准中，测试表明 Azure NetApp 文件常规卷可处理约 3,600 MiB/s 的顺序 64 KiB 纯读取和约 2,400 MiB/s 的顺序 64 KiB 纯写入。 在测试期间，采用 50/50 的混合比例时，总吞吐量与纯顺序读取工作负载相当。
对于纯读取，64-KiB 基线的性能略高于 256-KiB 基线。 但是，当涉及到纯写入和所有混合读/写工作负载时，256-KiB 基线优于 64 KiB，这表明对于高吞吐量工作负载而言，更大的块大小 256 KiB 的总体效率更高。
每次运行的工作负载读写混合比例调整 25%。
结果：256 KiB 顺序 I/O（不包含缓存）
在以下两个基线基准中，使用了 FIO 来测量 Azure NetApp 文件中单个常规卷可以传送的顺序 I/O（读取和写入）量。 为了生成反映完全未缓存的读取工作负载可以实现的真实带宽的基线，FIO 配置为使用参数 randrepeat=0 来运行数据集生成。 每次测试迭代都会通过读取完全独立的大型数据集而不是基准的一部分来抵消，以便清除基准数据集可能发生的任何缓存。
在此图中，测试表明 Azure NetApp 文件常规卷可处理约 3,500 MiB/s 的纯顺序 256 KiB 读取和约 2,500 MiB/s 的纯顺序 256 KiB 写入。 在测试期间，采用 50/50 的混合比例时，总吞吐量峰值高于纯顺序读取工作负载。
并行网络连接 (nconnect)
以下测试显示了使用具有 64 KiB 随机工作负载和 1 TiB 数据集的单个客户端的高 I/OP 基准。 生成的工作负载组合每次使用不同的 I/O 深度。 为了提升单个客户端工作负载的性能，使用了 nconnect 装载选项，与不使用 nconnect 装载选项相比，这提高了并行度。 这些测试仅在不包含缓存的情况下运行。
结果：64KiB 顺序 I/O、读取吞吐量缓存对比
为了演示缓存如何影响性能结果，在以下微基准比较中使用了 FIO 来测量 Azure NetApp 文件中单个常规卷可以提供的顺序 I/O（读取和写入）量。 此测试与部分可缓存工作负载可能提供的好处形成鲜明对比。
在不包括缓存的结果中，测试旨在缓解上述基线基准中所述的任何缓存。
在另一个结果中，对没有 randrepeat=0 参数并使用循环测试迭代逻辑在一段时间缓慢填充缓存的 Azure NetApp 文件常规卷使用了 FIO。 这些因素的组合产生了不确定的缓存量，从而提高了总体吞吐量。 与不使用缓存运行的测试相比，此配置产生的整体读取性能略好。
图形中显示的测试结果显示了有和没有缓存影响的读取性能的并行比较情况，其中有缓存时产生了高达约 4500 MiB/秒的读取吞吐量，而没有缓存时达到了约 3600 MiB/秒。
并排比较（使用和不使用 nconnect）
下图并排比较了使用和不使用 nconnect 时的 64 KiB 顺序读写情况，以突出显示使用 nconnect 时的性能改进：整体吞吐量更高、延迟更低。
