Amazon Elastic Compute Cloud
Windows 实例用户指南
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。点 击 Getting Started with Amazon AWS to see specific differences applicable to the China (Beijing) Region.

I/O 特征和监控

在给定卷配置中,某些 I/O 特性会对 EBS 卷的性能表现造成影响。SSD 卷 (即通用型 SSD (gp2) 和预配置 IOPS SSD (io1)) 能够提供一致的性能,无论 I/O 操作是随机的还是顺序的。HDD 卷 (即吞吐优化 HDD (st1) 和Cold HDD (sc1)) 仅当 I/O 操作是大型顺序操作时才能提供最佳性能。要了解 SSD 和 HDD 卷在您的应用程序中性能如何,务必要知道卷上的需求之间的联系、卷能支持的 IOPS 数量、完成 I/O 操作所需的时间,以及卷的吞吐量限制。

IOPS

IOPS 是表示每秒输入/输出操作数的度量单位。操作数以 KiB 来度量,底层驱动技术确定卷类型计算为单次 I/O 的最大数据量。SSD 卷的最大 I/O 大小为 256 KiB,HDD 卷的最大 I/O 大小为 1024 KiB,因为 SSD 卷比 HDD 卷处理小型或随机 I/O 的效率高很多。

当小型 I/O 操作在物理上连续进行时,Amazon EBS 会尝试将这些操作合并为单个 I/O,直至最大大小。例如,对于 SSD 卷,一个 1024 KiB 的 I/O 操作计为 4 个操作 (1,024÷256=4),而 8 个 32 KiB 的连续 I/O 操作计为 1 个操作 (8×32=256)。但是,8 个随机 32 KiB I/O 操作将被计为 8 个操作。每个低于 32 KiB 的 I/O 操作计为 1 个操作。

类似地,对于由 HDD 支持的卷,一个 1024 KiB 的 I/O 操作和 8 个顺序 128 KiB 操作将被计为一个操作。但是,8 个随机 128 KiB I/O 操作计为 8 个操作。

这样,当您创建支持 3000 IOPS (通过将 io1 配置为 3000 IOPS 或将 gp2 卷大小确定为 1000 GiB) 的 SSD 卷时,您就可以将它连接到一个 EBS 优化实例,该实例可以提供足够的带宽,您可以每秒传输最高 3000 次数据 I/O,其吞吐量由 I/O 大小决定。

卷队列长度和延迟

卷队列长度是指等待设备处理的 I/O 请求的数量。延迟为 I/O 操作的实际端到端客户端时间,也就是说,从将 I/O 发送到 EBS 到接收来自 EBS 的确认以表示 I/O 读取或写入完成所经过的时间。队列长度必须进行适当调整,以便与 I/O 大小和延迟匹配,避免在来宾操作系统上或在到 EBS 的网络链路上产生瓶颈。

每个工作负载的最佳队列长度不同,具体取决于您的特定应用程序对于 IOPS 和延迟的敏感程度。如果您的工作负载未提供足够的 I/O 请求来充分利用 EBS 卷的可用性能,则卷可能无法提供您预置的 IOPS 或吞吐量。

事务密集型应用程序对 I/O 延迟增加很敏感,很适合使用 SSD 支持的 io1gp2 卷。您可以通过使卷保持较小的队列长度和较高的 IOPS 数量,来维持高 IOPS 和低延迟。持续迫使一个卷的 IOPS 高于它能够支持的 IOPS 可能增加 I/O 延迟。

吞吐量密集型应用程序对 I/O 延迟增加较不敏感,很适合使用 HDD 支持的 st1sc1 卷。您可以在执行大型顺序 I/O 时维持大队列长度,从而对 HDD 卷保持高吞吐量。

I/O 大小和卷吞吐量限制

对于 SSD 卷,如果 I/O 大小非常大,由于达到卷的吞吐量限制,您的 IOPS 数可能会少于预配置数量。例如,对于具有可用突增额度的 1000 GiB 以下的 gp2 卷,IOPS 限制为 3000,卷吞吐量限制为 160 MiB/s。如果您正在使用 256 KiB 的 I/O 大小,则您的卷在 IOPS 为 640 时将达到其吞吐量限制 (640 x 256 KiB = 160 MiB)。当 I/O 大小较小 (如 16 KiB) 时,这个卷可以支持 3000 IOPS,这是因为吞吐量远低于 160 MiB/s (这些例子都假设卷的 I/O 不会达到实例的吞吐量限制。)有关每种 EBS 卷类型吞吐量限制的更多信息,请参阅 Amazon EBS 卷类型

对于较小的 I/O 操作,从实例内部进行度量时,您可能会看到 IOPS 值高于预配置值。当实例操作系统在将小型 I/O 操作传递到 Amazon EBS 之前将其合并为一个较大的操作时,会发生这种情况。

对于 HDD 支持的 st1sc1 卷,如果您的工作负载使用顺序 I/O,则从实例内部进行度量时,您的 IOPS 值可能会高于预期数量。当实例操作系统将顺序 I/O 进行合并,并以 1024 KiB 大小为单位来对其进行计数时,会发生这种情况。如果您的工作负载使用小型随机 I/O,则吞吐量可能会低于您的预期。这是因为我们会将每个随机的非顺序 I/O 计入总的 IOPS 计数,这可能导致您比预期更快达到卷的 IOPS 限制。

无论您采用何种 EBS 卷类型,如果您的 IOPS 或吞吐量与您在配置中的预期不同,请确保 EC2 实例带宽并不是导致这种结果的限制因素。您应始终使用最新一代的 EBS 优化实例 (或包含 10 Gb/s 网络连接的实例) 以实现最佳性能。有关更多信息,请参阅 Amazon EC2 实例配置。未达到预期 IOPS 的另一个可能原因是未对 EBS 卷执行足够多的 I/O 操作。

使用 CloudWatch 监控 I/O 特性

您可以通过每个卷的 CloudWatch 指标监控这些 I/O 特性。要考虑的重要指标包括:

  • BurstBalance

  • VolumeReadBytes

  • VolumeWriteBytes

  • VolumeReadOps

  • VolumeWriteOps

  • VolumeQueueLength

BurstBalance 以剩余余额百分比的形式显示 gp2, st1, and sc1 卷的突增存储桶余额。当您的突增存储桶耗尽时,卷 I/O 点数 (对于 gp2 卷) 或卷吞吐量点数 (对于 st1sc1 卷) 会限制为基准。检查 BurstBalance 值以确定卷是否因为此原因而受限制。

HDD 支持的 st1sc1 卷最适用于最大 I/O 为 1024KiB 的工作负载。要确定卷的平均 I/O 大小,请将 VolumeWriteBytes 除以 VolumeWriteOps。同样的计算也适用于读取操作。如果平均 I/O 大小低于 64 KiB,则提高发送到 st1sc1 卷的 I/O 操作的大小应该能够提高性能。

注意

如果平均 I/O 大小达到或接近 44 KiB,说明您可能是在不支持间接描述符的情况下使用实例或内核。所有 Linux 内核 3.8 及更高版本的内核上具有此支持,任何当代实例也具有此支持。

如果您的 I/O 延迟高于您的所需,请检查 VolumeQueueLength,以确保应用程序尝试驱动的 IOPS 不会超过您的配置。如果您的应用程序需要的 IOPS 数量超出您的卷所能提供的数量,则应考虑使用基本性能水平较高的较大 gp2 卷,或使用预配置 IOPS 更高的 io1 卷,以实现更短的延迟。

有关 Amazon EBS I/O 特征的更多信息,请参阅本主题上的 Amazon EBS:为性能而设计 re:Invent 演示文稿。