了解并优化 Azure 文件共享性能

Azure 文件存储可满足大多数应用程序和用例的性能要求。 本文介绍影响文件共享性能的不同因素，以及如何优化工作负荷Azure 文件存储的性能。

存储性能术语表

在阅读本文之前，了解与存储性能相关的一些关键术语会很有帮助：

• 每秒 IO 操作次数 (IOPS)

  IOPS（每秒输入/输出操作数）衡量的是每秒进行的文件系统操作数。 在Azure 文件存储文档中，术语“IO”与术语“操作”和“事务”可互换。

• I/O 大小

  I/O 大小（有时称为块大小）是指应用程序用于对存储执行单个输入/输出 (I/O) 操作的请求大小。 根据应用程序的不同，I/O 尺寸的范围可以从较小的 4 KiB 到更大尺寸。 I/O 大小在可实现的吞吐量中起着重要作用。

• 吞吐量

  吞吐量衡量每秒从存储读取或写入存储的位数，以每秒兆字节（MiB/秒）度量。 若要计算吞吐量，请将 IOPS 和 I/O 大小相乘。 例如，10,000 IOPS × 1 MiB I/O 大小 = 10 GiB/s，而 10,000 IOPS × 4 KiB I/O 大小 = 38 MiB/s。

• 延迟

  延迟是延迟的同义词，以毫秒为单位（ms）。 有两种类型的延迟：端到端延迟和服务延迟。 有关详细信息，请参阅延迟。

• 队列深度

  队列深度是存储资源在任意时刻可处理的挂起 I/O 请求数。 有关详细信息，请参阅队列深度。

根据使用模式选择媒体层

Azure 文件存储提供了两个存储媒体层，可用于平衡性能和价格：SSD 和 HDD。 在存储帐户级别为文件共享选择媒体层。 在特定媒体层中创建存储帐户后，无法在 不手动迁移到新文件共享的情况下移动到其他媒体层。

在 SSD 和 HDD 文件共享之间进行选择时，请考虑计划Azure 文件存储上运行的预期使用模式的要求。 如果需要大量的 IOPS、快速数据传输速度或低延迟，请选择 SSD 文件共享。

下表汇总了 SSD 和 HDD 文件共享之间的预期性能目标。 有关详细信息，请参阅 Azure 文件存储可伸缩性和性能目标。

SSD 文件共享采用预配模型，可根据共享大小保证以下性能指标。 有关详细信息，请参阅预配的 v1 模型。

性能最佳做法

无论是评估新工作负荷还是现有工作负荷的性能要求，了解使用模式都有助于实现可预测的性能。

• 延迟敏感度： 对读取延迟敏感且对最终用户具有较高可见性的工作负荷更适用于 SSD 文件共享，这可以为读取和写入操作提供单毫秒延迟（对于较小的 I/O 大小小于 2 毫秒）。

• IOPS 和吞吐量要求： SSD 文件共享支持比 HDD 文件共享更大的 IOPS 和吞吐量限制。 有关详细信息，请参阅 文件共享缩放目标。

• 工作负荷持续时间和频率： 与长时间运行的频繁工作负荷相比，短（分钟）和不频繁（每小时）工作负荷不太可能达到 HDD 文件共享的上限。 在 SSD 文件共享上，工作负荷持续时间有助于根据预配的存储、IOPS 和吞吐量确定要使用的正确性能配置文件。 一个常见的错误是仅运行几分钟的性能测试，这通常是误导性的。 若要获取真实的性能视图，请务必按足够高的频率测试足够长的时间。

• 工作负荷并行化： 对于并行执行作的工作负荷（例如，在同一客户端上通过多个线程、进程或应用程序实例），SSD 文件共享比 HDD 文件共享具有明显的优势：SMB 多通道。 有关详细信息，请参阅改进 SMB Azure文件共享性能。

• API 操作分布：元数据密集型工作负荷（例如针对大量文件执行读取操作的工作负荷）更适合 SSD 文件共享。 有关详细信息，请参阅 元数据或命名空间密集型工作负荷。

延迟

考虑延迟时，首先了解Azure 文件存储如何确定延迟。 最常见的度量是与端到端延迟和服务延迟指标关联的延迟。 使用这些 事务指标 ，通过显示应用程序流量在传入和传出客户端时花费的时间，有助于识别客户端延迟和网络问题。

• 端到端延迟 (SuccessE2ELatency) 是指事务执行完整往返所花费的总时间（完整往返从客户端开始，跨网络，传到 Azure 文件存储服务，然后返回客户端的）。

• 服务延迟（SuccessServerLatency）是事务仅在Azure 文件存储内往返所需的时间。 此度量不包括任何客户端或网络延迟。

  

SuccessE2ELatency 值和 SuccessServerLatency 值之间的差异是可能由网络或客户端引起的延迟。

将客户端延迟与服务延迟（在此情况下，是 Azure 文件存储性能）相混淆的情况很常见。 例如，如果服务延迟报告为低延迟，而端到端延迟显示请求延迟非常高，则全部耗时都花在往返客户端的传输过程中，而不是耗费在 Azure 文件存储 服务中。

此外，如图所示，你离服务越远，延迟体验越慢，实现任何云服务的性能缩放限制就越困难。 从本地访问Azure 文件存储时，这种情况尤其如此。 虽然Azure ExpressRoute等选项非常适合本地，但它们仍然与在同一Azure区域中完全运行的应用程序（计算 + 存储）的性能不匹配。

队列深度

队列深度是存储资源可处理的未完成 I/O 请求数。 随着存储系统使用的磁盘从 HDD 轴（IDE、SATA、SAS）演变为固态设备（SSD、NVMe），它们也演变为支持更高的队列深度。 队列深度较低的一个示例是单个客户端与大型数据集中的单个文件进行顺序交互的工作负载。 相比之下，支持多个线程和多个文件的并行的工作负载可以轻松实现高队列深度。 由于Azure 文件存储是一种分布式文件服务，它跨越数千个Azure群集节点，旨在大规模运行工作负荷、生成和测试具有高队列深度的工作负荷。

可以通过多种不同的方式实现高队列深度。 若要确定工作负荷的队列深度，请将客户端数乘以线程数（客户端×文件×线程 = 队列深度）。

下表说明了可用于实现更高队列深度的各种组合。 虽然队列深度可以超过 64 这一最佳值，但不建议这样做。 如果这样做，你将看不到更多性能提升，并且由于 TCP 饱和，延迟可能会增加。

单线程与多线程应用程序

Azure 文件存储最适合多线程应用程序。 了解多线程对工作负荷的性能影响的最简单方法是按 I/O 演练方案。 在以下示例中，你有一项工作负载，需要尽可能快地将 10,000 个小文件复制到 Azure 文件共享，或从 Azure 文件共享中复制出来。

此表根据按 4 KiB 块大小写入的单线程应用程序，细分在 Azure 文件共享上创建单个 16 KiB 文件所需的时间（以毫秒为单位）。

在此示例中，从六个操作创建单个 16 KiB 文件大约需要 14 毫秒。 如果单线程应用程序要将 10,000 个文件移动到 Azure 文件共享，该操作耗时为 140,000 毫秒（14 毫秒 × 10,000），即 140 秒，因为这些文件是逐个按顺序移动的。 每个请求的服务时间主要取决于计算和存储彼此之间的距离，如上一部分所述。

通过使用八个线程而不是一个线程，可以将上述工作负荷从 140,000 毫秒（140 秒）减少到 17,500 毫秒（17.5 秒）。 如下表所示，与每次只移动 1 个文件相比，并行移动 8 个文件时，移动相同数量的数据所需时间可减少 87.5%。

另请参阅

• 故障排除 Azure 文件共享性能问题
• 监视 Azure 文件存储
• 规划 Azure 文件部署
• 了解 Azure 文件存储计费
• Azure 文件存储定价