IOPS 卷队列长度和延迟 I/O 大小和容量吞吐量限制使用监控 I/O 特征 CloudWatch 监控实时 I/O 性能统计信息相关资源

亚马逊 EBS I/O 特征和监控

在给定的卷配置上，某些 I/O 特征会驱动 EBS 卷的性能行为。

SSD-backed 无论 I/O 操作是随机还是顺序操作，卷、通用固态硬盘（io1和io2）和预置的 IOPS 固态硬盘（和）都能提供稳定的性能。gp2 gp3
HDD-backed 容量、吞吐量优化型硬盘 (st1sc1) 和冷硬盘 () 只有在大量连续 I/O 操作时才能提供最佳性能。

要了解 SSD 和 HDD 卷在应用程序中的执行情况，了解卷需求、可用的 IOPS 数量、完成 I/O 操作所需的时间以及卷的吞吐量限制之间的关系非常重要。

IOPS

IOPS 是表示每秒 input/output 操作数的计量单位。这些操作以 KiB 为单位进行测量，底层驱动器技术决定了卷类型算作单 I/O个数据的最大数据量。 I/O 固态硬盘卷的大小上限为 256 KiB，硬盘卷的大小上限为 1,024 KiB，这是因为固态硬盘卷处理小容量或随机容量的效率要高 I/O得多。

当小型 I/O 操作在物理上是连续操作时，Amazon EBS 会尝试将它们合并为单个 I/O 操作，最大规模不超过最大 I/O 规模。同样，当 I/O 操作大于最大 I/O 规模时，Amazon EBS 会尝试将其拆分为较小的 I/O 操作。下表显示了一些示例。

卷类型	最大 I/O 尺寸	I/O 从您的应用程序中进行操作	IOPS 数量	备注
SSD	256 KiB	1 x 1024 KiB 操作 I/O	4（1024÷256=4）	亚马逊 EBS 将 1,024 KiB 的操作拆分为四个较小的 256 KiB I/O 操作。
		8 x 连续的 32 KiB 操作 I/O	1（8x32=256）	亚马逊 EBS 将八个连续的 32 KiB I/O 操作合并为一个 256 KiB 的操作。
		8 个随机 32 KiB 操作 I/O	8	亚马逊 EBS 单独计算随机 I/O 操作。
HDD	1,024 KiB	1 x 1024 KiB 操作 I/O	1	该 I/O 操作已经等于最大大 I/O 小。它不会被合并或拆分。
		8 x 连续的 128 KiB 操作 I/O	1（8x128=1024）	亚马逊 EBS 将八个连续的 128 KiB I/O 操作合并为一个 1,024 KiB 的单个操作。 I/O
		8 个随机 32 KiB 操作 I/O	8	亚马逊 EBS 单独计算随机 I/O 操作。

因此，当您创建支持 3,000 IOPS 的 SSD-backed 卷（通过预置一个io1或io2卷 3,000 IOPS，将gp2卷大小调整为 1,000 GiB，或者使用gp3卷），并将其连接到可以提供足够带宽的 EBS-optimized 实例时，您每秒最多可以传输 3,000 I/Os 个数据，吞吐量由大小决定。 I/O

卷队列长度和延迟

卷队列长度是指设备待处理 I/O 请求的数量。延迟是指 I/O 操作的真正端到端客户端时间，换句话说，从向 EBS 发送到收 I/O 到 EBS 确认 I/O 读取或写入已完成所经过的时间。必须根据 I/O 大小和延迟正确校准队列长度，以避免在客户机操作系统或 EBS 网络链路上造成瓶颈。

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

Transaction-intensive 应用程序对 I/O 延迟增加很敏感，非常适合 SSD-backed 容量。您可以通过使卷保持较小的队列长度和较高的 IOPS 数量，来维持高 IOPS 和低延迟。持续向卷推动 IOPS 多于其可用容量可能会导致 I/O 延迟延长。为了达到最大一致性，对于 1 分钟 1,000 个预调配 IOPS，卷必须保持平均队列深度（四舍五入到最接近的整数）1。例如，对于预置了 3,000 IOPS 的卷，队列深度平均值必须为 3。

Throughput-intensive 应用程序对 I/O 延迟增加不那么敏感，并且非常适合 HDD-backed 容量。在执行大规模、连续执行时，您可以通过保持较长的队列长度来保持较高的 HDD-backed 卷吞吐量 I/O。

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

对于 SSD-backed 卷，如果您的 I/O 大小非常大，则由于达到了卷的吞吐量限制，您遇到的 IOPS 数量可能会少于预置的 IOPS。例如，低于 1,000 GiB 且可用突增积分的gp2卷的 IOPS 限制为 3,000，卷吞吐量限制为 250。 MiB/s如果您使用的是 256 KiB I/O 的大小，则您的卷将达到 1000 IOPS（1000 x 256 KiB = 250 MiB）的吞吐量限制。对于较小 I/O 的大小（例如 16 KiB），由于吞吐量远低于 250，因此同样的卷可以维持 3,000 IOPS。 MiB/s（这些示例假设您的卷 I/O 未达到实例的吞吐量限制。）有关每种 EBS 卷类型吞吐量限制的更多信息，请参阅 Amazon EBS 卷类型。

对于较小的 I/O 操作，您可能会看到从实例内部衡量的 IOPS 值高于预置的 IOPS 值。当实例操作系统在将小 I/O操作传递给 Amazon EBS 之前将其合并为更大的操作时，就会发生这种情况。

如果您的工作负载使用连续开 I/Os 启 HDD-backed st1和sc1容量，则从实例内部测得的 IOPS 数可能会高于预期。当实例操作系统按顺序合并 I/Os 并以 1,024 个 KiB-sized 单位进行计数时，就会发生这种情况。如果您的工作负载使用少量或随机使用 I/Os，则吞吐量可能会低于预期。这是因为每次随机的、非连续的都会 I/O 计入总 IOPS 数量，这可能会导致您比预期更快地达到卷的 IOPS 限制。

无论您的 EBS 卷类型如何，如果您的配置没有达到预期的 IOPS 或吞吐量，请确保您的 EC2 实例带宽不是限制因素。为了获得最佳性能，您应始终使用当前一代的 EBS-optimized 实例（或包含 10 个 Gb/s 网络连接的实例）。未达到预期 IOPS 的另一个可能原因是，您对 EBS 卷的驱动量不够 I/O 。

使用监控 I/O 特征 CloudWatch

您可以使用每个卷的音CloudWatch 量指标来监控这些 I/O 特征。

监视是否处于停机状态 I/O

VolumeStalledIOCheck 监控 EBS 卷的状态以确定您的卷何时受损。该指标是一个二进制值，它将根据 EBS 卷能否完成 I/O 操作，返回 01（通过）或（失败）状态。

如果该VolumeStalledIOCheck指标失效，您可以等待 AWS 问题解决，也可以采取措施，例如更换受影响的卷或停止并重启该卷所连接的实例。在大多数情况下，当该指标失败时，EBS 将在几分钟内自动诊断并恢复您的卷。您可以使用中的 “暂停 I/O” 操作 AWS Fault Injection Service 来运行对照实验，测试您的架构，并根据该指标进行监控，从而提高存储故障的恢复能力。

监控音量的 I/O 延迟

您可以使用 VolumeAvgReadLatency 和 VolumeAvgWriteLatency 指标分别监控 Amazon EBS 卷的读取和写入操作的平均延迟。您可以在中使用延迟注入操作 AWS Fault Injection Service 来运行对照实验，测试您的架构并根据该指标进行监控，从而提高存储性能下降的弹性。

如果您的 I/O 延迟高于您的要求，请确保您的应用程序尝试推动的 IOPS 或吞吐量不会超过您为卷预置的吞吐量。您可以使用 VolumeAvgIOPS 和 VolumeAvgThroughput 指标来监控一分钟内驱动到卷的平均 IOPS 和吞吐量，然后将其与卷的预调配 IOPS 和吞吐量进行比较。如果卷在该分钟内没有驱动任何操作，则指标将报告值零（0）。如果高 IOPS 或吞吐量的爆发持续时间短于分钟间隔，则卷会遭遇微爆，但平均 IOPS 和吞吐量指标可能会报告，您的性能低于卷的预调配 IOPS 或吞吐量限制。要确定您的卷在给定的分钟内是否出现性能突，您可以使用 VolumeIOPSExceededCheck 和 VolumeThroughputExceededCheck 指标。您可以监控这些指标，以确定在给定的分钟内，您的工作负载持续尝试驱动高于卷的预置性能的 IOPS 或吞吐量。如果在该分钟的任意一秒驱动的 IOPS 持续超过卷的预调配 IOPS 性能，则返回 VolumeIOPSExceededCheck 指标。1如果在该分钟的任意一秒驱动的吞吐量持续超过卷的预调配吞吐量性能，则返回 VolumeThroughputExceededCheck 指标。1如果驱动的 IOPS 和吞吐量在卷的预调配性能范围内，则返回 0 指标。

如果您的应用程序需要的 IOPS 数量超出您的卷所能提供的数量，则应考虑使用以下选项之一：

gp3、io2 或 io1 卷，预置了足够 IOPS 以实现所需延迟
更大的 gp2 卷，提供足够的基准 IOPS 性能

HDD-backed st1而且sc1卷专为在充分利用 1,024 KiB 最大大 I/O 小的工作负载中表现最佳而设计。要确定音量的平均大 I/O 小，请VolumeWriteBytes除以VolumeWriteOps。同样的计算也适用于读取操作。如果平均 I/O 大小低于 64 KiB，则增加发送到st1或sc1卷的 I/O 操作大小应该可以提高性能。

监控 `gp2`、`st1 和 sc1` 卷的突发存储桶余额

BurstBalance 以剩余余额百分比的形式显示 gp2、st1 和 sc1 卷的突增存储桶余额。当您的突增存储桶耗尽时，容量 I/O （gp2卷）或卷吞吐量（st1和sc1卷）会被限制到基准。检查 BurstBalance 值以确定卷是否因为此原因而受限制。有关可用亚马逊 EBS 指标的完整列表，请参阅亚马逊 EBS 的亚马逊 CloudWatch 指标和适用于实例的亚马逊 EBS 指标。 Nitro-based

监控实时 I/O 性能统计信息

您可以访问连接到亚马逊 EC2 实例的 Amazon EBS 卷的实时详细性能统计数据。 Nitro-based

您可以组合这些统计数据来得出平均延迟和 IOPS，或者检查 I/O 操作是否已完成。您还可以查看应用程序超过 EBS 卷或所附加实例的预调配 IOPS 或吞吐量限制的总时间。通过跟踪这些统计数据随时间推移的增长情况，您可以确定是否需要增加预调配 IOPS 或吞吐量限制，以优化应用程序的性能。详细的性能统计数据还包括读取和写入 I/O 操作的直方图，这些直方图通过跟踪 I/O 延迟区间内完成的 I/O 操作总数来提供延迟分布情况。

有关更多信息，请参阅 Amazon EBS 详细性能统计数据。