Azure 高级存储：高性能设计

适用于：✔️ Linux VM ✔️ Windows VM ✔️ 灵活规模集 ✔️ 统一规模集

本文提供了使用 Azure 高级存储构建高性能应用程序的准则。 可以将本文档中提供的说明与适用于应用程序所使用技术的性能最佳实践结合使用。 为了阐明这些准则，我们在本文档中使用了在高级存储上运行的 SQL Server 作为示例。

由于我们在本文中所处理的性能方案是针对存储层的，因此你需要对应用程序层进行优化。 例如，如果要在高级存储上托管 SharePoint 场，则可使用本文中的 SQL Server 示例来优化数据库服务器。 你还可以优化 SharePoint 场的 Web 服务器和应用程序服务器以获得最高性能。

本文帮助你回答关于如何在高级存储上优化应用程序性能的以下常见问题：

• 如何度量应用程序性能？
• 为什么看不到预期的高性能？
• 哪些因素会影响高级存储上的应用程序性能？
• 这些因素如何影响高级存储上的应用程序性能？
• 如何针对每秒输入/输出操作 (IOPS)、带宽和延迟进行优化？

我们所提供的这些准则是专门针对高级存储的，因为在高级存储上运行的工作负载对性能高度敏感。 我们会在适当的时候提供示例。 你也可以将这些准则中的一部分应用于在标准存储磁盘的基础结构即服务 (IaaS) VM 上运行的应用程序。

如果您对高级存储不熟悉，请在开始之前阅读以下内容：为 IaaS VM 选择 Azure 磁盘类型和高级页 Blob 存储帐户的可伸缩性目标。

应用程序性能指标

我们通过使用性能指标来评估应用程序是否运行良好，例如：

• 应用程序处理用户请求的速度。
• 应用程序对于每个请求处理的数据量。
• 应用程序在特定时段内处理的请求数。
• 提交请求后，用户需要等待多久才能获取响应。

这些性能指标相对应的技术术语是：IOPS、吞吐量或带宽、延迟。

我们会在本部分讨论使用高级存储情况下的常见性能指标。 在磁盘性能应用程序清单部分中，了解如何衡量应用程序的这些性能指标。 在之后的“优化应用程序性能”部分中，你将了解影响这些性能指标的各种因素，以及优化它们的建议。

IOPS

IOPS 是指应用程序在一秒内发送到存储磁盘的请求数。 可以按顺序或随机读取或写入输入/输出操作。 联机事务处理 (OLTP) 应用程序（例如在线零售网站）需要即时处理多个并发用户请求。 用户请求是插入和更新密集型数据库事务，必须由应用程序快速处理。 因此，OLTP 应用程序需要非常高的 IOPS。

OLTP 应用程序通常会处理数百万个小型和随机的 I/O 请求。 如果应用程序是这样的，则必须在设计应用程序基础结构时针对 IOPS 进行优化。 有关要实现高 IOPS 需考虑的所有因素的详细信息，请参阅优化应用程序性能。

将高级存储磁盘连接到高规模 VM 时，Azure 会根据磁盘规格为你预配保障数目的 IOPS。 例如，P50 磁盘会预配 7,500 IOPS。 每个高规模 VM 大小还存在一个其所能承受的特定 IOPS 限制。

吞吐量

吞吐量或带宽是指应用程序在指定时间间隔内发送到存储磁盘的数据量。 如果应用程序执行的输入/输出操作使用的 I/O单位很大，则它需要高吞吐量。 数据仓库应用程序往往会发出扫描密集型操作（这些操作一次就会访问大量的数据），并且通常会执行批处理操作。 换而言之，此类应用程序需要更高的吞吐量。 如果应用程序是这样的，则必须在设计其基础结构时针对吞吐量进行优化。 在下一部分，我们会讨论为了实现此优化而必须调整的因素。

将高级存储磁盘连接到高规模 VM 时，Azure 会根据磁盘规格预配吞吐量。 例如，P50 磁盘会预配 250 MB/秒的磁盘吞吐量。 每个高规模 VM 还存在一个其所能承受的特定吞吐量限制。

吞吐量和 IOPS 之间存在一个关系，如以下公式所示。

确定应用程序所需的最佳吞吐量和 IOPS 值很重要。 当你尝试优化其中一个指标时，另一个指标也会受影响。 有关优化 IOPS 和吞吐量的详细信息，请参阅优化应用程序性能。

延迟

延迟是指应用程序接收单个请求，将其发送到存储磁盘，然后再将响应发送到客户端所花的时间。 延迟是除 IOPS 和吞吐量之外应用程序性能的另一个关键度量指标。 高级存储磁盘的延迟是指该磁盘检索请求的信息并将其发送回应用程序所花的时间。 高级存储提供稳定的低延迟。 高级磁盘的设计旨在为大多数 I/O 操作提供个位数毫秒级延迟。 如果在高级存储磁盘上启用 ReadOnly 主机缓存，则可获得相当低的读取延迟。 有关磁盘缓存的详细信息，请参阅磁盘缓存。

当你优化应用程序以获得更高的 IOPS 和吞吐量时，它会影响应用程序的延迟。 在调整应用程序性能以后，应评估应用程序的延迟，以免出现意外的高延迟行为。

托管磁盘上的某些控制平面操作可能会将磁盘从一个存储位置移到另一个存储位置。 在存储位置之间移动磁盘是通过在后台复制数据来协调的，这可能需要几个小时才能完成。 通常，该时长小于 24 小时，具体取决于磁盘中的数据量。 在此期间，由于一些读取可能被重定向到原始位置，应用程序可能会经历比平常更高的读取延迟，并且需要更长时间才能完成。

在后台复制期间，对大多数磁盘类型的写入延迟没有影响。 对于高级 SSD v2 和超级磁盘，如果磁盘具有 4K 扇区大小，则读取延迟会更高。 如果磁盘的扇区大小为 512e，则读取和写入延迟会更高。

以下控制平面操作可能会在存储位置之间移动磁盘，并导致延迟增加：

• 更新存储类型
• 分离磁盘以及将磁盘从一个 VM 附加到另一个 VM。
• 从 VHD 创建托管磁盘。
• 从快照创建托管磁盘
• 将非托管磁盘转换为托管磁盘

磁盘性能应用程序清单

设计在高级存储上运行的高性能应用程序时，第一步是了解应用程序的性能要求。 收集性能要求后，即可优化应用程序，使性能得到最大优化。

在上一节中，我们介绍了常见的性能指标：IOPS、吞吐量、延迟。 必须确定对应用程序最重要的性能指标，以便为用户提供理想体验。 例如，对于需要在一秒内处理数百万事务的 OLTP 应用程序来说，提高 IOPS 最重要。 对于需要在一秒内处理大量数据的数据仓库应用程序来说，高吞吐量很关键。 对于实时应用程序（例如视频直播网站）来说，极低的延迟至关重要。

接下来，请衡量一下应用程序在其整个生存期的最大性能要求。 使用以下示例清单作为开头。 记录正常、高峰、空闲工作负载期间的最大性能要求。 确定所有工作负载级别的要求以后，就可以确定应用程序的总体性能要求。

例如，电子商务网站的正常工作负载是指该网站在一年中的大多数日子需要处理的事务数。 网站的高峰工作负载是指该网站在假日或进行特殊促销活动时候需要处理的事务数。 高峰工作负载通常会在有限的时段内出现，但可能需要应用程序扩展到正常运行的两倍或以上。 找出第 50 百分位、第 90 百分位和第 99 百分位的具体要求。 此信息有助于筛掉性能要求中的任何离群值，让你能够专注于针对正确的值进行优化。

应用程序性能要求清单

如果在已经有一个应用程序的情况下想要转到高级存储，请首先为现有应用程序构建前述清单。 然后，在高级存储上构建应用程序的原型，根据“优化应用程序性能”中描述的准则设计应用程序。 下一篇文章说明那些可以用来收集性能度量的工具。

用于衡量应用程序性能要求的计数器

要衡量应用程序的性能要求，最好的方式是使用服务器的操作系统提供的PerfMon 监视工具。 可在 Windows 中使用 PerfMon，在 Linux 中使用 iostat。 这些工具会根据前面部分所述的每个指标捕获计数器。 必须在应用程序运行其正常、高峰和空闲工作负载时捕获这些计数器的值。

PerfMon 计数器适用于处理器、内存以及服务器的每个逻辑磁盘和物理磁盘。 将高级存储磁盘用于 VM 时，物理磁盘计数器适用于每个高级存储磁盘，逻辑磁盘计数器适用于在高级存储磁盘上创建的每个卷。 必须捕获承载应用程序工作负荷的磁盘的值。 如果逻辑磁盘和物理磁盘之间存在一对一映射，则可以参考物理磁盘计数器。 否则，请参考逻辑磁盘计数器。

在 Linux 中，iostat 命令会生成 CPU 和磁盘使用率报告。 磁盘使用率报告会按物理设备或分区提供统计信息。 如果数据库服务器的数据和日志位于不同的磁盘上，则请针对两种磁盘收集此类数据。 下表描述了针对磁盘、处理器和内存的计数器。

详细了解 iostat 和 PerfMon。

优化应用程序性能

影响运行在高级存储上的应用程序的性能的主要因素包括：I/O 请求的性质、VM 大小、磁盘大小、磁盘数目、磁盘缓存、多线程处理和队列深度。 可使用系统提供的设置来控制其中部分因素。

大多数应用程序不会提供一个选项来直接更改 I/O 大小和队列深度。 例如，如果你使用的是 SQL Server，则不能选择 I/O 大小和队列深度。 SQL Server 会选择最佳的 I/O 大小和队列深度值以实现最佳性能。 必须了解两类因素对应用程序性能的影响，这样你才能根据性能需要预配相应的资源。

此部分从始至终都需要参考你所创建的应用程序要求清单，以便确定相关需求以优化应用程序性能。 根据该清单，你可以确定本部分中的哪些因素需要调整。

若要了解每个因素对应用程序性能的影响，可在应用程序安装以后运行基准测试工具。 如需在 Windows 和 Linux VM 上运行常见基准测试工具的步骤，请参阅本文档末尾的基准测试一文。

迅速优化 IOPS、吞吐量和延迟

下表汇总了性能因素以及优化 IOPS、吞吐量和延迟所需的步骤。 此汇总之后的部分会更深入地介绍每个因素。

有关 VM 大小以及每种类型的 VM 可用的 IOPS、吞吐量和延迟的详细信息，请参阅 Azure 中虚拟机的大小。

I/O 请求的性质

I/O 请求是应用程序在执行的输入/输出操作单元。 识别 I/O 请求的性质（是随机还是顺序，是读取还是写入，是小还是大）有助于确定应用程序的性能要求。 了解 I/O 请求的性质很重要，这有助于在设计应用程序基础结构时进行正确的决策。 必须均匀地分布 I/O 以尽可能实现最佳性能。

I/O 大小是较为重要的因素之一。 I/O 大小是由应用程序生成的输入/输出操作请求的大小。 I/O 大小会显著影响性能，尤其是在应用程序可以实现的 IOPS 和带宽方面。 下面的公式说明了 IOPS、I/O 大小和带宽/吞吐量之间的关系。

某些应用程序允许更改其 I/O 大小，而某些应用程序则不允许。 例如，SQL Server 会自行确定最佳 I/O 大小，不允许用户对其进行更改。 另一方面，Oracle 提供了名为 DB_BLOCK_SIZE 的参数，可用于配置数据库的 I/O 请求大小。

如果你使用的应用程序不允许更改 I/O 大小，则可根据本文中的准则来优化与你的应用程序最相关的性能 KPI。 例如：

• OLTP 应用程序会生成数以百万计的小型和随机 I/O请求。 为了处理这些类型的 I/O请求，必须将应用程序基础结构设计为能够实现高 IOPS。
• 数据仓库应用程序会生成大型和顺序 I/O请求。 为了处理这些类型的 I/O请求，必须将应用程序基础结构设计为能够实现高带宽或吞吐量。

如果您使用的应用程序允许更改 I/O 大小，可以结合其他性能准则，使用关于 I/O 大小的这条经验法则：

• 通过降低 I/O 大小来提高 IOPS。 例如，对 OLTP 应用程序使用 8 KB 的 I/O 大小。
• 通过提高 I/O 大小来提高带宽/吞吐量。 例如，数据仓库应用程序的大小为 1,024 KB。

下面是一个如何计算应用程序的 IOPS 和吞吐量/带宽的示例。

请考虑使用 P30 磁盘的应用程序。 P30 磁盘能够实现的最大 IOPS 和吞吐量/带宽分别是 5,000 IOPS 和 200 MB/秒。 如果你的应用程序需要 P30 磁盘的最大 IOPS，并且你使用较小的 I/O 大小（如 8 KB），则你会获得的带宽为 40 MB/秒。如果你的应用程序需要 P30 磁盘的最大吞吐量/带宽，并且你使用较大的 I/O 大小（如 1,024 KB），则获得的 IOPS 会更少，例如 200 IOPS。

调整 I/O大小，使之满足你的应用程序的 IOPS 和吞吐量/带宽要求。 下表总结了 P30 磁盘的不同 I/O 大小以及相应的 IOPS 和吞吐量。

要获取比单个高级存储磁盘的最大值还要高的 IOPS 和带宽，可将多个高级磁盘一起条带化。 例如，将两个 P30 磁盘条带化，以获得总共 10,000 IOPS 或 400 MB/秒的吞吐量。如下一部分所述，必须使用支持磁盘 IOPS 和吞吐量组合的 VM 大小。

要见证 I/O 大小对应用程序性能的影响，可以在 VM 和磁盘上运行基准测试工具。 创建多个测试运行并对每个运行使用不同的 I/O 大小，即可观察相应的影响。 有关详细信息，请参阅本文档末尾的基准测试文章。

大型 VM 大小

开始设计应用程序时，首先要做的一件事就是选择一个 VM 来托管你的应用程序。 高级存储提供高规模 VM 大小，它可以运行需要更高计算能力和本地高磁盘 I/O 性能的应用程序。 这些 VM 为本地磁盘提供更快的处理器、更高的内存内核比和固态硬盘 (SSD)。 DS 系列 VM 是支持高级存储的高规格 VM 的例子。

高规模 VM 提供不同的大小、不同数目的 CPU 核心、内存、OS 和临时磁盘大小。 每种虚拟机(VM)规格还有可以附加到虚拟机上的数据磁盘的最大数量。 所选的 VM 大小会影响你的应用程序可以具备的处理能力、内存和存储容量。 它还会影响计算和存储成本。 例如，以下是 DS 系列中最大 VM 的规格。

要查看所有可用 Azure VM 大小的完整列表，请参阅 Azure 中虚拟机的大小。 选择能够满足或者在扩展后能够满足所需应用程序性能要求的 VM 大小。 在选择 VM 大小时，还请考虑以下重要注意事项。

规模限制

每个 VM 和每个磁盘的最大 IOPS 限制是不同的，互不影响。 请确保应用程序所要实现的 IOPS 处于 VM 以及连接到 VM 的高级磁盘的限制内。 否则，应用程序性能就会受到限制。

举例来说，假设应用程序要求的 IOPS 最大值为 4,000。 为了实现此级别，你在 DS1 VM 上预配了一个 P30 磁盘。 P30 磁盘可以提供的 IOPS 最多为 5,000。 但是，DS1 VM 的 IOPS 限制为 3,200。 因此，应用程序性能受 VM 限制（3,200 IOPS）的约束，性能会下降。 为防止这种情况的发生，请选择都能满足应用程序要求的 VM 和磁盘大小。

操作成本

在许多情况下，与使用标准存储相比，使用高级存储的总体运行成本可能更低。

例如，考虑一个需要 16,000 IOPS 的应用程序。 要达到此性能，需要使用 Standard_D14 Azure IaaS VM，该 VM 可以使用 32 个标准存储 1-TB 磁盘来实现 16,000 的最大 IOPS。 每个 1-TB 标准存储磁盘最多可以实现 500 IOPS。

• 此 VM 每月的估计成本为 CNY10,171。
• 32 个标准存储磁盘每月的成本为 CNY8,847。
• 每月估计的总成本为 CNY19,018。

如果将相同的应用程序托管在高级存储上，需要的 VM 大小会降低，需要的高级存储磁盘数会减少，从而降低总体成本。 Standard_DS13 VM 可以使用 4 个 P30 磁盘来满足 16,000 IOPS 的要求。 DS13 VM 的最大 IOPS 为 25,600，每个 P30 磁盘的最大 IOPS 为 5,000。 总起来说，此配置可以达到 5,000 x 4 = 20,000 的 IOPS。

• 此 VM 每月的估计成本为 CNY5,081。
• 4 个 P30 高级存储磁盘每月的成本是 CNY3,625。
• 每月估计的总成本为 CNY8,706。

下表总结了这种情况下标准存储和高级存储的成本明细。

Linux 发行版

使用高级存储时，可以让运行 Windows 和 Linux 的 VM 获得相同级别的性能。 支持多种 Linux 发行版。 有关详细信息，请参阅 Azure 认可的 Linux 分发版本。

不同的发行版适合不同类型的工作负载。 取决于运行你的工作负载的发行版，你看到的性能级别会有所不同。 使用应用程序测试各种 Linux 发行版，选择最适合的。

使用高级存储运行 Linux 时，请查看所需驱动程序的最新更新，以确保实现高性能。

高级存储磁盘大小

高级存储提供了各种大小，以便你可以选择最适合需求的大小。 每种磁盘大小对 IOPS、带宽和存储设置了不同规格的限制。 选择正确的高级存储磁盘大小，具体取决于应用程序要求和高规模 VM 大小。 下表展示了磁盘大小及其功能。 目前，仅托管磁盘支持 P4、P6、P15、P60、P70 和 P80 大小。

*仅适用于启用按需突发的磁盘。
**仅适用于已启用增强性能（预览版）的磁盘。

选择多少磁盘取决于所选磁盘大小。 可以使用单个 P50 磁盘或多个 P10 磁盘来满足应用程序要求。 在做出选择时，请考虑此处列出的注意事项。

规模限制（IOPS 和吞吐量）

每种高级磁盘大小的 IOPS 和吞吐量限制都是不同的，与 VM 规模限制无关。 请确保磁盘的总 IOPS 和吞吐量处于所选 VM 大小的规模限制范围内。

例如，如果应用程序要求最多为 250 MB/秒的吞吐量，而你使用的是具有单个 P30 磁盘的 DS4 VM，则 DS4 VM 最多可提供 256 MB/秒的吞吐量。 但是，单个 P30 磁盘的吞吐量限制为 200 MB/秒。因此，由于磁盘限制，应用程序会被约束在 200 MB/秒。 为了克服这一限制，请为 VM 预配多个数据磁盘，或将磁盘大小重设为 P40 或 P50。

磁盘数目

通过评估应用程序要求，确定所需的磁盘数。 每种 VM 大小还设置了可以连接到 VM 的磁盘的数目限制。 通常情况下，该数目是核心数的两倍。 请确保所选 VM 大小能够支持所需磁盘数。

请记住，与标准存储磁盘相比，高级存储磁盘具有更高的性能。 如果要将应用程序从使用标准存储的 Azure IaaS VM 迁移到高级存储，可能只需较少的高级磁盘即可让应用程序实现相同的性能或更高的性能。

磁盘缓存

使用高级存储的高规模 VM 使用名为 BlobCache 的多层缓存技术。 BlobCache 使用主机 RAM 和本地 SSD 的组合来进行缓存。 此缓存适用于标准 HDD、标准 SSD 和高级 SSD 托管磁盘。 默认情况下，此缓存设置设置为 OS 磁盘的 ReadWrite ，并将数据磁盘的 ReadOnly 设置为 ReadWrite 。 启用磁盘缓存后，大规模 VM 可以实现超出基础磁盘性能的极高级别性能。

要详细了解 BlobCache 的工作原理，请参阅 Inside Azure 高级存储博客文章。

务必在正确的磁盘集上启用缓存。 是否应在磁盘上启用磁盘缓存取决于磁盘正在处理的工作负荷模式。 下表展示了 OS 和数据磁盘的默认缓存设置。

应对数据磁盘使用以下磁盘缓存设置：

ReadOnly

通过在数据磁盘上配置 ReadOnly 缓存，可以实现低读取延迟，并为应用程序获取非常高的读取 IOPS 和吞吐量，原因有两个原因：

1. 读取是从缓存执行的，发生在 VM 内存和本地 SSD 上，其速度要快于从数据磁盘执行的读取，后者发生在 Azure Blob 存储上。
2. 存储不会将缓存中处理的读取计入磁盘IOPS和吞吐量。 因此，应用程序可以实现更高的总 IOPS 和吞吐量。

ReadWrite

默认情况下，OS 磁盘已启用 ReadWrite 缓存。 我们最近还增加了对在数据磁盘上进行 ReadWrite 缓存的支持。 如果你使用的是 ReadWrite 缓存，则必须使用正确的方法将数据从缓存写入到永久性磁盘中。 例如，SQL Server 会自行将缓存数据写入永久性存储磁盘。 对不负责保留所需数据的应用程序使用 ReadWrite 缓存可能会在 VM 崩溃时导致数据丢失。

无

目前，只有数据磁盘支持“无”。 OS 磁盘不支持它。 如果在 OS 磁盘上设置了 None，它会在内部替代此设置，并将其设为 ReadOnly。

例如，可以按照以下步骤将以下准则应用于在启用了高级存储的 VM 上运行的 SQL Server：

1. 在托管数据文件的标准 HDD、标准 SSD 或高级 SSD 托管磁盘上配置 ReadOnly 缓存。
   1. 从缓存快速读取可以缩短 SQL Server 查询时间，因为从缓存检索数据页的速度要快于直接从数据磁盘检索。
   2. 从缓存中读取数据意味着可以从数据磁盘提供更多的吞吐量。 SQL Server 可以利用这额外的吞吐量来检索更多数据页和执行其他操作，例如备份/还原、批量加载以及索引重建。
2. 在托管日志文件的高级存储磁盘上配置 None 缓存。
   1. 日志文件主要具有写入密集型操作，因此它们不会受益于 ReadOnly 缓存。

优化 Linux Vm 的性能

对于所有高级 SSD 或超级磁盘，当已知不存在任何可能丢失数据的缓存时，可以禁用磁盘上文件系统的屏障以提高性能。 如果 Azure 磁盘缓存设置为 ReadOnly 或 None，则可以禁用屏障。 但是，如果缓存设置为 ReadWrite，则屏障应保持启用状态以确保写入持续性。 通常情况下，屏障默认启用，但你可以根据文件系统类型使用以下方法之一来禁用屏障：

• reiserFS：使用 barrier=none 装载选项来禁用屏障。 要显式启用屏障，请使用 barrier=flush。
• ext3/ext4：使用 barrier=0 装载选项来禁用屏障。 要显式启用屏障，请使用 barrier=1。
• XFS：使用 nobarrier 装载选项来禁用屏障。 要显式启用屏障，请使用屏障。 从主线 Linux 内核 4.10 版本开始，XFS 文件系统的设计始终确保持续性。 禁用屏障不起作用，“nobarrier”选项已弃用。 但是，某些 Linux 发行版可能已将这些更改反向移植到了拥有更早内核版本的发行版中。 请与你的发行版供应商联系，了解你正在运行的发行版和版本的状态。

磁盘条带化

当高性能虚拟机连接多个高级存储持久性磁盘时，可以将这些磁盘进行条带化，以聚合其 IOPS、带宽和存储容量。

在 Windows 上，可以使用存储空间将磁盘一起条带化。 必须为池中每个磁盘配置一个列。 否则，条带化卷的整体性能可能会低于预期，因为磁盘之间的通信分配不平均。

通过使用服务器管理器 UI，可以将列的总数设置为每个条带化卷最多 8 个。 连接 8 个以上的磁盘时，可使用 PowerShell 来创建卷。 借助 PowerShell，可以将列数设置为与磁盘数相等。 例如，如果单个条带集中有 16 个磁盘，请在 New-VirtualDisk PowerShell cmdlet 的 NumberOfColumns 参数中指定 16 列。

在 Linux 中，可使用 MDADM 实用工具将磁盘条带化。 有关如何在 Linux 上对磁盘进行条带化的步骤，请参阅 在 Linux 上配置软件 RAID。

条带大小

进行磁盘条带化操作时，一项重要配置是条带大小。 条带大小或块大小是应用程序可以在条带化卷上处理的最小数据块区。 配置的条带大小取决于应用程序类型及其请求模式。 如果选择了错误的条带大小，则可能导致 I/O 不一致，从而导致应用程序性能下降。

例如，如果应用程序生成的 I/O 请求大于磁盘条带大小，存储系统会将数据写在不止一个磁盘上，跨越条带单元的边界。 要访问该数据时，它必须跨多个条带单元进行搜索才能完成请求。 这种行为的累积效应就是性能大幅下降。 另一方面，如果 I/O 请求大小小于条带大小，并且其性质是随机的，则 I/O 请求可能会在同一磁盘上累积起来，导致瓶颈的出现，最终导致 I/O 性能下降。

请根据应用程序正在运行的工作负荷的类型，选择合适的条带大小。 对于随机的小型 I/O 请求，请使用较小的条带大小。 对于大型的顺序性的 I/O 请求，则请使用较大的条带大小。 对于要在高级存储上运行的应用程序，请找出相应的条带大小建议。 对于 SQL Server，如果工作负荷为 OLTP 工作负荷，请将条带大小配置为 64 KB；如果工作负荷为数据仓库型工作负荷，则请将条带大小配置为 256 KB。 有关详细信息，请参阅 Azure VM 上 SQL Server 的性能最佳做法。

多线程处理

Azure 将高级存储平台设计为可以进行大规模并行处理。 因此，相对于单线程应用程序，多线程应用程序可以实现更高的性能。 多线程应用程序会将其任务拆分成多个线程，并将 VM 和磁盘资源利用到极致，从而提高其执行效率。

例如，如果应用程序是在使用两个线程的单核 VM 上运行，则 CPU 可以在这两个线程之间进行切换以实现高效率。 当一个线程在等待磁盘 I/O 完成时，CPU 可以切换至另一个线程。 通过这种方式，两个线程可以完成比单个线程更多的任务。 如果 VM 有多个核心，则可进一步缩短运行时间，因为每个核心都可以并行运行任务。

你可能无法改变现成应用程序实现单线程处理或多线程处理的方式。 例如，SQL Server 能够处理多 CPU 和多核。 但是，SQL Server 会决定在什么情况下使用一个或多个线程来处理查询。 它可以运行查询，并使用多线程处理来生成索引。 如果一个查询需要先联接多个大型表并对数据进行排序然后才能返回给用户，则 SQL Server 很可能会使用多个线程。 用户无法控制 SQL Server 是使用单个线程还是多个线程来运行查询。

可以通过更改配置设置来影响应用程序的多线程处理或并行处理。 例如，对于 SQL Server，它是 max degree of parallelism 配置。 此设置称为 MAXDOP，它让你可以配置 SQL Server 在进行并行处理时能够使用的最大处理器数。 可为单个查询或索引操作配置 MAXDOP。 当你需要为性能关键型应用程序对系统资源进行平衡时，此功能会很有用。

例如，假设你的应用程序使用 SQL Server，并且正在同时运行一个大型查询和一个索引操作。 假设你想要让索引操作比大型查询具有更高的性能。 在这种情况下，可以将索引操作的 MAXDOP 值设置得高于查询的 MAXDOP 值。 这样一来，SQL Server 可以用于索引操作的处理器比用于大型查询的处理器更多。 请记住，你无法控制 SQL Server 用于每个操作的线程数。 你可以控制专用于多线程处理的处理器的最大数目。

详细了解 SQL Server 中的并行度。 了解应用程序中的此类设置如何影响多线程处理，以及如何配置它们以优化性能。

队列深度

队列深度、队列长度或队列大小是指系统中待处理的 I/O 请求的数目。 队列深度的值决定了应用程序可以让多少个 I/O 操作排队供存储磁盘处理。 它会影响本文中讨论过的所有三个应用程序性能指标：IOPS、吞吐量、延迟。

队列深度和多线程处理密切相关。 队列深度值表示应用程序可以实现的多线程处理的程度。 如果队列深度较大，则应用程序可以并发运行更多的操作，换言之，可以进行更多的多线程处理。 如果队列深度较小，则即使应用程序具备多线程能力，它也无法让足够多的请求排队来完成并发执行。

通常情况下，现成的应用程序不允许更改队列深度，因为设置不正确的话会适得其反。 应用程序会将队列深度设成合适的值以实现最佳性能。 但是，理解这一概念还是很重要的，这样你才能排查应用程序的性能问题。 也可通过在系统中运行基准测试工具来观察队列深度的影响。

某些应用程序提供可以影响队列深度的设置。 例如，上一部分介绍的 SQL Server 中的 MAXDOP 设置。 MAXDOP 是一种影响队列深度和多线程处理的方法，即便它不直接更改 SQL Server 的队列深度值。

高队列深度

高队列深度可以让更多操作在磁盘上排队。 磁盘可以提前知道其队列中的下一个请求。 因此，磁盘可以提前计划操作，按最佳顺序处理它们。 由于应用程序向磁盘发送了更多的请求，磁盘可以处理更多的并行 I/O。 最终，应用程序可以实现更高的 IOPS。 由于应用程序处理了更多的请求，应用程序的总吞吐量也会增加。

通常，在每个连接的磁盘存在 8 到 16+ 待处理 I/O 的情况下，应用程序可以实现最大吞吐量。 如果队列深度为 1，则应用程序不会将足够的 I/O 推送到系统，在给定时间内所能处理的 IO 数会较少。 换言之，吞吐量会降低。

例如，在 SQL Server 中，为某个查询将 MAXDOP 值设置为 4 就是告知 SQL Server 它最多可以使用 4 个核心来运行该查询。 SQL Server 会决定最佳队列深度值以及查询执行的核心数。

最佳队列深度

队列深度值过高也有其缺点。 如果队列深度值过高，则应用程序会尝试驱动非常高的 IOPS。 除非应用程序的永久性磁盘具有预配足够的 IOPS，否则非常高的队列深度值会对应用程序延迟造成负面影响。 以下公式展示了 IOPS、延迟、队列深度之间的关系。

不应将队列深度配置为某个很高的值，而应将其配置为最佳值，从而确保应用程序实现足够的 IOPS，但又不会影响延迟。 例如，如果应用程序延迟需要为 1 毫秒，则要实现 5,000 IOPS 所需的队列深度为：QD = 5000 x 0.001 = 5。

条带化卷的队列深度

条带化卷应保持足够高的队列深度，使得每个磁盘都有各自的高峰队列深度。 例如，某个应用程序推送的队列深度为 2，条带中有 4 个磁盘。 这两个 I/O 请求会前往两个磁盘，其余两个磁盘处于空闲状态。 因此，请将队列深度配置为让所有磁盘都能够处于繁忙状态。 以下公式说明了如何确定条带化卷的队列深度。

限制

高级存储会预配指定数目的 IOPS 和吞吐量，具体取决于你选择的 VM 大小和磁盘大小。 任何时候，只要应用程序尝试驱动的 IOPS 或吞吐量超出了这些限制（VM 或磁盘能够处理的量），高级存储就会对其施加限制。 结果是应用程序性能下降，这可能意味着较高的延迟、较低的吞吐量或较低的 IOPS。

如果高级存储不对此进行限制，则应用程序可能超过其资源的处理能力，从而彻底崩溃。 为了避免因限制而造成的性能问题，请始终为应用程序预配足够的资源。 请考虑我们在之前的 VM 大小和磁盘大小部分讨论过的内容。 要了解你需要哪些资源来托管应用程序，最好的方式是进行基准测试。

后续步骤

如果要对磁盘进行基准测试，请参阅以下文章：

• 对于 Linux：在 Azure 磁盘存储上对应用程序进行基准测试
• 对于 Windows：对磁盘进行基准测试

了解有关可用磁盘类型的详细信息：

• 对于 Linux：选择磁盘类型
• 对于 Windows：选择磁盘类型

对于 SQL Server 用户，请参阅有关 SQL Server 性能最佳做法的文章：

• Azure VM 中的 SQL Server 的性能最佳做法
• Azure 高级存储为 Azure VM 中的 SQL Server 提供最高性能