Amazon EBS I/O 特征和监控 - Amazon EBS

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

Amazon EBS I/O 特征和监控

在给定的卷配置中,某些 I/O 特征决定了 EBS 卷的性能行为。

  • 无论操作是随机操作还是顺 I/O 序操作,SSD 支持的卷、通用型 SSD(gp2gp3io1和预配置 IOPS 固态硬盘(和io2)都能提供一致的性能。

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

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

IOPS

IOPS 是表示每秒 input/output 操作数的计量单位。操作以 KiB 为单位进行测量,底层驱动器技术确定一种卷类型算作单个的最大数据量,其效率要比 HDD 卷高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 x 1024 KiB 操作 I/O 4(1024÷256=4) 亚马逊 EBS 将 1,024 KiB 的操作拆分为四个较小的 I/O 256 KiB 操作。
8 次顺序 32 KiB 操作 I/O 1(8x32=256) Amazon EBS 将连续八个 32 KiB 操作合并为一个 256 KiB I/O 操作。
8 次随机 32 kiB 操作 I/O 8 Amazon 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 操作合并为一个 1,024 KiB I/O 操作。 I/O
8 次随机 32 kiB 操作 I/O 8 Amazon EBS 将随机 I/O 操作单独计数。

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

卷队列长度和延迟

卷队列长度是设备待处理 I/O 请求的数量。延迟是指 I/O 操作的真实 end-to-end客户端时间,换句话说,从向 EBS 发送 I/O 到收到 I/O 读取或写入已完成的确认之间经过的时间。必须根据 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-provisioned IOPS 值。当实例操作系统在将小型 I/O 操作传递到 Amazon EBS 之前将其合并为一个较大的操作时,会发生这种情况。

如果您的工作负载在支持 HDD st1sc1卷 I/Os 上使用顺序运行,则从实例内部测量的 IOPS 数量可能会高于预期。当实例操作系统按顺序合并 I/Os 并以 1,024 个 Kib 大小的单位进行计数时,就会发生这种情况。如果您的工作负载占总 IOPS 计数的小量或随机I/Os, you may experience a lower throughput than you expect. This is because we count each random, non-sequential I/O使用量,这可能会导致您比预期更快地达到卷的 IOPS 限制。

无论您的 EBS 卷类型如何,如果您在配置中没有达到预期的 IOPS 或吞吐量,请确保您的 EC2 实例带宽不是限制因素。为了获得最佳性能,您应始终使用最新一代的 EBS 优化实例(或包含 10 个 Gb/s 网络连接的实例)。未达到预期 IOPS 的另一个可能原因是,您开车不够 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)

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

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

  • gp3io2io1 卷,预置了足够 IOPS 以实现所需延迟

  • 更大的 gp2 卷,提供足够的基准 IOPS 性能

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

监控gp2st1sc1音量的突发存储桶平衡

BurstBalance 以剩余余额百分比的形式显示 gp2st1sc1 卷的突增存储桶余额。当您的突发存储桶耗尽时,容量 I/O (对于gp2卷)或卷吞吐量(st1sc1卷)将限制为基准。检查 BurstBalance 值以确定卷是否因为此原因而受限制。有关可用 Amazon EBS 指标的完整列表,请参阅亚马逊 EBS 的亚马逊 CloudWatch 指标基于 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 演示文稿:A mazon EBS:为性能而设计。