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

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

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

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

  • SSD无论是随机还是顺序的 I/O 操作，都支持通用SSDIOPSSSD型（io1和io2）和已配置卷（和），均可提供一致的性能。gp2 gp3

  • HDD由支持的卷，即吞吐量优化 HDD (st1) 和 Cold HDD (sc1)，仅当 I/O 操作量大且连续运行时，才能提供最佳性能。

要了解HDD卷在应用程序中的表现SSD以及卷的性能，重要的是要了解卷的需求、IOPS可用卷的数量、完成 I/O 操作所需的时间以及卷的吞吐量限制之间的联系。

IOPS

IOPS是一种计量单位，表示的效率input/output operations per second. The operations are measured in KiB, and the underlying drive technology determines the maximum amount of data that a volume type counts as a single I/O. I/O size is capped at 256 KiB for SSD volumes and 1,024 KiB for HDD volumes because SSD volumes handle small or random I/O远高于HDD体积。

当小型 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 个 1024 KiB I/O 操作 4（1024÷256=4） 亚马逊将 1,024 个 I/O 操作EBS拆分为四个较小的 256 KiB 操作。
8 个连续 32KiB I/O 操作 1（8x32=256） 亚马逊将八个EBS连续的 32 KiB I/O 操作合并为一个 256 KiB 的操作。
8 个随机 32 KiB I/O 操作 8 Amazon 单独EBS计算随机 I/O 操作。
HDD 1,024 KiB 1 个 1024 KiB I/O 操作 1 I/O 操作已经等于最大 I/O 大小。它不会被合并或拆分。
8 个连续 128KiB I/O 操作 1（8x128=1024） 亚马逊将八个连续的 128 KiB I/O 操作EBS合并为一个 1,024 KiB 的 I/O 操作。
8 个随机 32 KiB I/O 操作 8 Amazon 单独EBS计算随机 I/O 操作。

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

卷队列长度和延迟

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

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

事务密集型应用程序对增加的 I/O 延迟很敏感，非常适合SSD由支持的卷。您可以通过IOPS保持较低的队列长度和较高的卷IOPS可用队列数量来保持较高的延迟。持续IOPS向某个卷驱动的数量超过其可用容量可能会导致 I/O 延迟增加。

吞吐量密集型应用程序对增加的 I/O 延迟不太敏感，非常适合由支持的卷。HDD在执行大型顺序 I/O 时，您可以通过保持较高的队列长度来保持HDD支持卷的高吞吐量。

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

对于SSD由支持的卷，如果您的 I/O 大小非常大，则由于已达到卷的吞吐量限制，您遇到的数量可能会少IOPS于预配置的卷。例如，如果gp2容量低于 1,000 GiB 且可用的突发积分，其上IOPS限为 3,000，而卷吞吐量限制MiB/s. If you are using a 256 KiB I/O size, your volume reaches its throughput limit at 1000 IOPS (1000 x 256 KiB = 250 MiB). For smaller I/O sizes (such as 16 KiB), this same volume can sustain 3,000 IOPS because the throughput is well below 250 MiB/s. (These examples assume that your volume's I/O为 250 则未达到实例的吞吐量限制。） 有关每种EBS卷类型的吞吐量限制的更多信息，请参阅Amazon EBS 卷类型。

对于较小的 I/O 操作，您可能会看到从实例内部测量的 higher-than-provisionedIOPS值。当实例操作系统在将小型 I/O 操作传递给 Amazon EBS 之前将其合并到较大的操作中时，就会发生这种情况。

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

无论您的EBS卷类型如何，如果您的配置中没有达到预期的IOPS或吞吐量，请确保您的EC2实例带宽不是限制因素。您应始终使用最新一代的、EBS经过优化的实例（或包含 10 个Gb/s network connectivity) for optimal performance. Another possible cause for not experiencing the expected IOPS is that you are not driving enough I/O卷的实例）。EBS

使用监控 I/O 特性 CloudWatch

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

监视停滞的 I/O

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

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

监控卷的 I/O 延迟

您可以分别使用和VolumeAvgWriteLatency指标监控 Amazon EBS 卷的读取VolumeAvgReadLatency和写入操作的平均延迟。

如果您的 I/O 延迟高于您的需求，请确保您的应用程序尝试驱动的吞吐量IOPS或吞吐量不会超过您为卷预配置的容量。使用以下公式计算特定时间段内卷的平均值IOPS和吞吐量，然后将其与卷的预配置IOPS和吞吐量进行比较。

                                  Sum(VolumeReadOps) + Sum(VolumeWriteOps) 
Estimated average IOPS in ops/s = ----------------------------------------
                                        Period - Sum(VolumeIdleTime)
                                        (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / 1024
Estimated average throughput in KiB/s = -----------------------------------------------------
                                                    Period - Sum(VolumeIdleTime)

您还可以监控VolumeIOPSExceededCheck和VolumeThroughputExceededCheck指标，以确定您的工作负载是否持续尝试驱动IOPS或吞吐量在给定分钟内超过卷的预配置性能。如果驱动量IOPS持续超过您的卷的预配置IOPS性能，则该VolumeIOPSExceededCheck指标将返回1。如果驱动吞吐量持续超过卷的预配置吞吐量性能，则该VolumeThroughputExceededCheck指标将返回1。如果驱动IOPS且吞吐量在卷的预配置性能范围内，则返回0指标。

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

  • A gp3 io2、或io1卷，其预配置的容量足IOPS以达到所需的延迟

  • 更大的gp2音量可提供足够的基准IOPS性能

HDD-backe sc1 dst1，卷旨在在利用最大 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指标的完整列表，请参阅亚马逊针对亚马逊的 CloudWatch 指标 EBS和基于 Nitro的实例的亚马逊EBS指标。

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

您可以访问附加到基于 Nitro的亚马逊EC2实例的亚马逊EBS卷的实时详细性能统计数据。

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

有关更多信息，请参阅 Amazon EBS 的详细绩效统计数据。

相关资源

有关 Amazon EBS I/O 特性的更多信息，请参阅以下 re: Invent 演示文稿：亚马EBS逊：为性能而设计。