为什么我的 Amazon EBS 卷会遇到 I/O 等待时间长、队列长度增加以及延迟激增的问题?

1 分钟阅读
0

我的 Amazon Elastic Block Store (Amazon EBS) 卷遇到了 I/O 等待时间长、队列长度增加和延迟激增的问题。为什么会发生这种情况?

简短描述

对于 Amazon EBS 卷,队列长度的增加和较长的 IO 等待时间表明 I/O 操作完成存在延迟。

以下是延迟增加的最常见原因:

  • EBS 卷已达到其吞吐量或 IOPS 限制。
  • 已达到 Amazon Elastic Compute Cloud (Amazon EC2) 实例的吞吐量或 IOPS 限制。
  • 正在发生微突增。
  • 该卷已从快照中恢复并正在初始化。
  • 该卷的基础存储子系统存在问题。

解决方案

该卷已达到其吞吐量或 IOPS 限制

EBS 卷根据其类型和大小设置吞吐量和 IOPS 限制。您也可以为 gp3io1io2 卷类型设置这些限制。如果达到此类限制,就可能会遇到延迟。要确定您的吞吐量和 IOPS 限制,请参阅如何计算 Amazon EBS 卷的最大 IOPS 和吞吐量? 然后,可以使用 CloudWatch 指标来检查 EC2 实例的 EBS 卷是否已达到吞吐量或 IOPS 限制

如果您经常达到吞吐量或 IOPS 限制,请考虑更改卷类型或大小以符合应用程序需求。最佳实践是在测试环境中针对工作负载对 EBS 卷进行基准测试,以确定哪种卷类型最适合您。

已达到实例的吞吐量或 IOPS 限制

EBS 优化型实例具有最大聚合吞吐量和 IOPS,可以在连接到该实例的所有 EBS 卷上实现该吞吐量和 IOPS。您可能会看到 I/O 等待时间过长且延迟增加,但您的卷未达到其吞吐量或 IOPS 限制。如果发生这种情况,请检查卷的吞吐量或 IOPS 是否已达到实例的吞吐量或 IOPS 限制

例如,您的 gp3 卷为 1 TiB,预调配 IOPS 为 16,000,吞吐量为 700 MiB/s(连接到 t3.medium 实例)。一个 t3.medium 实例可以实现 260.57 MiB/s 吞吐量的最大性能,在与其连接的所有卷上聚合 11,800 IOPS。24 小时内,该实例仅在 30 分钟内达到最大性能。然后,性能被限制到 43.43 MiB/s 吞吐量的基准,所有连接卷的总吞吐量为 2,000 IOPS。尽管您的单个卷可以维持高达 700 MiB/s 和 16,000 IOPS,但该实例无法达到此性能。

如果您的应用程序性能需求超出实例的容量,则可以考虑更改实例类型以符合您的工作负载需求。有关可用实例类型及其各自 Amazon EBS 吞吐量和 IOPS 限制的列表,请参阅 EBS 优化型实例规格

正在发生微突增

当卷突增 IOPS 或吞吐量的时间比收集周期短得多时,就会发生微突增。微突增不会反映在 Amazon CloudWatch 指标上,如果未执行检查,则可能会错过微突增情况。要确定问题是否为微突增,请参阅如何识别我的 EBS 卷是否存在微突增并防止这种情况发生?

该卷已从快照中恢复并正在初始化

从快照中恢复卷时,将从 Amazon Simple Storage Service (Amazon S3) 中提取其数据并写入该卷。此过程称为初始化。首次访问每个数据块时,初始化可能会导致 I/O 操作延迟增加。

为了减少初始化对卷性能的影响,可以通过读取卷上的块来强制初始化卷。您也可以开启 Amazon EBS 快速快照恢复,以便在创建卷时完全初始化。

该卷的基础存储子系统存在问题

如果您尝试上述所有故障排除步骤,但仍遇到高延迟,请联系 AWS Support。


相关信息

我该如何使用 CloudWatch 指标来计算我的 EBS 卷所提供的平均吞吐量和平均 IOPS 数量?

解决从 EBS 快照恢复 Amazon EBS 卷时遇到的 I/O 延迟问题

AWS 官方
AWS 官方已更新 1 年前