你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
了解 Azure 文件存储的性能
Azure 文件存储可满足大多数应用程序和用例的性能要求。 本文介绍了可能影响文件共享性能的不同因素，还介绍了如何针对工作负载优化 Azure 文件共享的性能。
适用于
| 文件共享类型 | SMB | NFS |
|---|---|---|
| 标准文件共享 (GPv2)、LRS/ZRS |  |
 |
| 标准文件共享 (GPv2)、GRS/GZRS | |
|
| 高级文件共享 (FileStorage)、LRS/ZRS | |
|
术语表
在阅读本文之前，了解与存储性能相关的一些关键术语会很有帮助：
每秒 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/秒，而 10,000 IOPS * 4 KiB I/O 大小 = 38 MiB/秒。
延迟
延时的同义词是延迟，通常以毫秒 (ms) 度量。 有两种类型的延迟：端到端延迟和服务延迟。 有关详细信息，请参阅延迟。
队列深度
队列深度是存储资源在任何时间可处理的挂起 I/O 请求数。 有关详细信息，请参阅队列深度。
基于使用模式选择性能层
Azure 文件存储提供了一系列存储层，通过允许以适当的性能和价格水平存储数据来帮助降低成本。 Azure 文件存储大致提供两个性能层：标准和高级。 标准文件共享托管在硬盘驱动器 (HDD) 支持的存储系统上，而高级文件共享则由固态硬盘 (SSD) 提供支持来提高性能。 标准文件共享具有多个存储层（事务优化、热和冷），你可在这些存储层之间无缝移动，来实现静态数据存储和事务价格的最大化。 但是，如果没有在不同存储帐户之间以物理方式迁移数据，则无法在标准层和高级层之间移动。
在标准文件共享和高级文件共享之间进行选择时，请务必了解计划针对 Azure 文件存储运行的预期使用模式的要求。 如果需要大量 IOPS、极快的数据传输速度或非常低的延迟，应选择高级 Azure 文件共享。
下表汇总了标准层与高级层之间的预期性能目标。 有关详细信息，请参阅 Azure 文件存储可伸缩性和性能目标。
| 了解模式要求 | Standard | 高级 |
|---|---|---|
| 写入延迟（个位数毫秒） | 是 | 是 |
| 读取延迟（个位数毫秒） | 否 | 是 |
高级文件共享提供一个预配模型，可根据共享大小保证以下性能配置文件。 有关详细信息，请参阅预配模型。 每当文件共享的流量低于基线 IOPS 时，突发额度都将累积在突发桶中。 稍后将使用获得的额度，在超过基线 IOPS 时启用突发。
| 容量 (GiB) | 基线 IOPS | 突发 IOPS | 突发额度 | 吞吐量（流入量 + 流出量） |
|---|---|---|---|---|
| 100 | 3,100 | 最高 10,000 | 24,840,000 | 110 MiB/秒 |
| 500 | 3,500 | 最高 10,000 | 23,400,000 | 150 MiB/秒 |
| 1,024 | 4,024 | 最高 10,000 | 21,513,600 | 203 MiB/秒 |
| 5,120 | 8,120 | 最大 15,360 | 26,064,000 | 613 MiB/秒 |
| 10,240 | 13,240 | 最大 30,720 | 62,928,000 | 1,125 MiB/秒 |
| 33,792 | 36,792 | 最大 100,000 | 227,548,800 | 3,480 MiB/秒 |
| 51,200 | 54,200 | 最大 100,000 | 164,880,000 | 5,220 MiB/秒 |
| 102,400 | 100,000 | 最大 100,000 | 0 | 10,340 MiB/秒 |
性能清单
无论是评估新工作负载还是现有工作负载的性能要求，了解使用模式都将有助于实现可预测的性能。 请咨询存储管理员或应用程序开发人员来确定以下使用模式。
延迟敏感度：用户是否正在打开文件或正在与在 Azure 文件存储上运行的虚拟桌面交互？ 下面这些工作负载实例对读取延迟敏感的，并且对最终用户具有较高的可见性。 这些类型的工作负载更适用于高级 Azure 文件共享，对于读取和写入操作提供个位数毫秒级延迟（对于较小的 I/O，< 2 ms）。
IOPS 和吞吐量要求：高级文件共享可支持比标准文件共享更高的 IOPS 和吞吐量上限。 有关详细信息，请参阅文件共享扩缩目标。
工作负载持续时间和频率：与长时间运行的频繁发生的工作负载相比，运行时间短（以分钟计）且运行不频繁（以每小时计）的工作负载更不可能达到标准文件共享的性能上限。 在高级文件共享上，根据预配大小确定要使用的适当性能配置文件时，工作负载持续时间很有用。 根据工作负载需要突发的时长及其在低于基线 IOPS 的情况下花费的时长，你可确定你是否正在累积足够的突发额度，以在高峰时间持续满足工作负载的需求。 与过度预配文件共享相比，找到适当的平衡将降低成本。 一个常见错误是仅运行性能测试几分钟，这通常具有误导性。 若要获取真实的性能视图，请务必按足够高的频率测试足够长的时间。
工作负载并行化：对于通过同一客户端上的多个线程、进程或应用程序实例等并行执行操作的工作负载，高级文件共享相比于标准文件共享具有明显的优势：SMB 多通道。 有关详细信息，请参阅提高 SMB Azure 文件共享性能。
API 操作分布：工作负载元数据是否执行大量文件打开/关闭操作？ 对大量文件执行读取操作的工作负载常会出现这种情况。 请参阅元数据或命名空间工作负载繁重。
延迟
在考虑延迟时，请务必先了解如何使用 Azure 文件存储确定延迟。 最常见的度量是与端到端延迟和服务延迟指标关联的延迟。 使用这些事务指标可以确定应用程序流量在传入和传出客户端的过程中花费的时间，从而帮助识别客户端延迟和/或网络问题。
端到端延迟 (SuccessE2ELatency) 是指事务执行完整往返所花费的总时间（完整往返从客户端开始，跨网络，传到 Azure 文件存储服务，然后返回客户端的）。
服务延迟 (SuccessServerLatency) 是指事务仅在 Azure 文件存储服务内往返所需的时间。 这不包括任何客户端或网络延迟。
SuccessE2ELatency 值和 SuccessServerLatency 值之间的差异是可能由网络或客户端引起的延迟。
将客户端延迟与服务延迟（在此情况下，是 Azure 文件存储性能）相混淆的情况很常见。 例如，如果服务延迟报告低延迟，而端到端报告了非常高的请求延迟，则表明所有时间都花在了传入和传出客户端的过程中，而不是花在 Azure 文件存储服务中。
此外，如图所示，离服务越远，延迟体验就越慢，使用任何云服务实现性能缩放限制的难度就越大。 从本地访问 Azure 文件存储时尤其如此。 虽然 ExpressRoute 等选项非常适合本地，但它们仍然与仅在同一 Azure 区域中运行的应用程序（计算 + 存储）的性能不匹配。
提示
要对到 Azure 连接的网络功能进行基线化，一种有效且实用的方法是使用 Azure 中的 VM 来测试本地与 Azure 之间的性能。 通常，工作负载可能会因 ExpressRoute 线路或 VPN 网关大小不足或路由错误而变慢。
队列深度
队列深度是存储资源可处理的未完成 I/O 请求数。 随着存储系统使用的磁盘已从 HDD 主轴（IDE、SATA、SAS）演变为固态设备（SSD、NVMe），它们也演变为支持更高队列深度。 队列深度较低的一个示例是由单个客户端组成的工作负载与大型数据集中的单个文件串行交互。 相比之下，支持多个线程和多个文件的并行的工作负载可以轻松实现高队列深度。 由于 Azure 文件存储是跨数千个 Azure 群集节点的分布式文件服务，旨在大规模运行工作负载，因此建议生成和测试队列深度较高的工作负载。
可通过多种不同的方式与客户端、文件和线程结合使用来实现高队列深度。 若要确定工作负载的队列深度，请将客户端数、文件数和线程数相乘（客户端数 * 线程数 * 线程数 = 队列深度）。
下表说明了可用于实现更高队列深度的各种组合。 虽然可超过最佳队列深度 64，但建议不要超过它。 如果这样做，你将看不到更多性能提升，并且由于 TCP 饱和，延迟可能会增加。
| 客户端 | 文件 | 线程 | 队列深度 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 1 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 64 |
提示
若要实现性能上限，请确保工作负载或基准测试是包含多个文件的多线程测试。
单线程应用程序与多线程应用程序
Azure 文件存储最适合多线程应用程序。 要了解多线程对工作负载的性能影响，最简单的方法是按 I/O 来演练方案。 在以下示例中，有一个工作负载需要将 10,000 个小文件尽快复制到 Azure 文件共享或从 Azure 文件共享复制。
此表根据按 4 KiB 块大小写入的单线程应用程序，细分在 Azure 文件共享上创建单个 16 KiB 文件所需的时间（以毫秒为单位）。
| I/O 操作 | 创建 | 4 KiB 写入 | 4 KiB 写入 | 4 KiB 写入 | 4 KiB 写入 | 关闭 | 总计 |
|---|---|---|---|---|---|---|---|
| 线程 1 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
在此示例中，通过 6 个操作创建单个 16 KiB 文件大约需要 14 ms。 如果单线程应用程序想要将 10,000 个文件移动到 Azure 文件共享，则相当于 140,000 ms (14 ms * 10,000) 或 140 秒，因为每个文件均按顺序一次移动一个。 请记住，服务每个请求的时间主要取决于计算和存储之间的距离，如上一部分所述。
通过使用 8 个线程而不是 1 个线程，上述工作负载可以从 140,000 ms（140 秒）缩短到 17,500 ms（17.5 秒）。 如下表所示，当你并行移动 8 个文件，而不是一次移动一个文件时，移动相同的数据量可节省 87.5% 的时间。
| I/O 操作 | 创建 | 4 KiB 写入 | 4 KiB 写入 | 4 KiB 写入 | 4 KiB 写入 | 关闭 | 总计 |
|---|---|---|---|---|---|---|---|
| 线程 1 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
| 线程 2 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
| 线程 3 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
| 线程 4 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
| 线程 5 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
| 线程 6 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
| 线程 7 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |
| 线程 8 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 ms |