本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Amazon EBS I/O 特性和监控
在给定卷配置中,某些 I/O 特性会对 EBS 卷的性能表现造成影响。
-
支持 SSD 的卷、通用型 SSD(
gp2
和gp3
)和预配置 IOPS 固态硬盘(io1
和io2
),无论 I/O 操作是随机还是顺序操作,都能提供一致的性能。 -
支持 HDD 的卷,即吞吐量优化 HDD (
st1
) 和 Cold HDD (sc1
),仅在 I/O 操作量大且连续运行时才能提供最佳性能。
要了解 SSD 和 HDD 卷在您的应用程序中性能如何,务必要知道卷上的需求之间的联系、卷能支持的 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得多。
当小型 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) | Amazon EBS 将 1,024 个 I/O 操作拆分为四个较小的 256 KiB 操作。 |
8 个连续 32KiB I/O 操作 | 1(8x32=256) | Amazon EBS 将 8 个连续 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) | Amazon EBS 将 8 个连续 128 KiB I/O 操作合并为一个 1,024 KiB I/O 操作。 | ||
8 个随机 32 KiB I/O 操作 | 8 | Amazon EBS 分别计算随机 I/O 操作。 |
因此,当您创建一个支持 3,000 IOPS 的 SSD 卷(通过预置具有 3,000 IOPS 的 io1
或 io2
卷、将 gp2
卷大小调整为 1,000 GiB,或者使用 gp3
卷)并将其附加到可以提供足够带宽的 EBS 优化实例时,您可以每秒传输最高 3000 次数据 I/O,其吞吐量由 I/O 大小决定。
卷队列长度和延迟
卷队列长度是指等待设备处理的 I/O 请求的数量。延迟是 I/O 操作的真实 end-to-end客户机时间,换句话说,就是从向 EBS 发送 I/O 到收到来自 EBS 的 I/O 读取或写入已完成的确认之间经过的时间。队列长度必须进行适当调整,以便与 I/O 大小和延迟匹配,避免在访客操作系统上或在到 EBS 的网络链路上产生瓶颈。
每个工作负载的最佳队列长度不同,具体取决于您的特定应用程序对于 IOPS 和延迟的敏感程度。如果您的工作负载未提供足够的 I/O 请求来充分利用 EBS 卷的可用性能,则卷可能无法提供您预置 IOPS 或吞吐量。
事务密集型应用程序对 I/O 延迟增加很敏感,很适合支持 SSD 的卷。您可以通过使卷保持较小的队列长度和较高的 IOPS 数量,来维持高 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-provisioned IOPS 值。当实例操作系统在将小型 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 操作返回 0
(通过)或1
(失败)状态。
如果该VolumeStalledIOCheck
指标失败,您可以等待 Amazon 问题得到解决,也可以采取措施,例如更换受影响的卷或停止并重新启动该卷所连接的实例。在大多数情况下,当该指标失败时,EBS 将在几分钟内自动诊断并恢复您的卷。您可以使用中的 Pause I/O 操作 Amazon 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 数量超出您的卷所能提供的数量,则应考虑使用以下选项之一:
-
gp3
、io2
或io1
卷,预置了足够 IOPS 以实现所需延迟 -
更大的
gp2
卷,提供足够的基准 IOPS 性能
HDD 支持的 st1
和 sc1
卷经过特别设计,旨在对使用 1024 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
值以确定卷是否因为此原因而受限制。有关可用 Amazon EBS 指标的完整列表,请参阅亚马逊针对亚马逊的 CloudWatch 指标 EBS和基于 Nitro 的实例的 Amazon EBS 指标。
监控实时 I/O 性能统计信息
您可以访问附加到基于 Nitro的亚马逊实例的 Amazon EBS 卷的实时详细性能统计数据。 EC2
您可以组合这些统计数据来得出平均延迟和 IOPS,或者检查 I/O 操作是否已完成。您还可以查看应用程序超过 EBS 卷或所连接实例的预配置 IOPS 或吞吐量限制的总时间。通过跟踪这些统计数据随时间推移的增长情况,您可以确定是否需要提高预配置 IOPS 或吞吐量限制以优化应用程序的性能。详细的性能统计数据还包括读取和写入 I/O 操作的直方图,这些直方图通过跟踪延迟区间内完成的 I/O 操作总数来提供 I/O 延迟的分布情况。
有关更多信息,请参阅 Amazon EBS 的详细绩效统计数据。
相关资源
有关 Amazon EBS I/O 特征的更多信息,请参阅以下 re:Invent 演示文稿:Amazon EBS:为性能而设计