为什么我的 Amazon EC2 实例在平均利用率很低时会超过其网络限制？

2 分钟阅读

我的 Amazon Elastic Compute Cloud（Amazon EC2）实例的平均利用率很低，但该实例仍超过其网络限制。

简短描述

您可以实时查询通过弹性网络适配器（ENA）支持增强型网络的实例的网络性能指标。这些指标提供了自上次重置设备以来每个网络接口上排队或丢弃的数据包数累积值。

下面列出了其中一些 ENA 指标：

**bw_in_allowance_exceeded：**由于入站聚合带宽超过实例的上限而排队或丢弃的数据包数。
**bw_out_allowance_exceeded：**由于出站聚合带宽超过实例的上限而排队或丢弃的数据包数。
**pps_allowance_exceeded：**由于双向每秒数据包数（PPS）超过实例的上限而排队或丢弃的数据包数。
**conntrack_allowance_exceeded：**由于实例的网络流量超过可以跟踪的最大连接数而排队或丢弃的数据包数。

网络性能规格因实例类型而异。要查看规格，请参阅最新一代实例。在某些情况下，即使在 Amazon CloudWatch 中看到的平均带宽或 PPS 很低，仍可能会出现排队或丢弃数据包的情况。例如，CloudWatch 中的 NetworkIn、NetworkOut、NetworkPacketsIn 或 NetworkPacketsOut 指标显示的数量可能并不表示将达到限制。

解决方法

微爆是上述症状最常见的原因。微爆是指短暂的需求激增，而随后的时段活动很少或无活动。这些突增通常仅持续几秒、数毫秒甚至数微秒。就微爆而言，上一节中列出的 CloudWatch 指标不够精细，无法反映这些微爆。

平均值是如何计算的

上一节中列出的 CloudWatch 中的 EC2 指标是每隔 1 分钟采样一次得到的。这些指标捕获的是该时段内传输的总字节数或数据包总数。然后按 5 分钟的时段将这些采样值聚合并发布到 CloudWatch。该时段内的每项统计数据都返回不同的采样值：

总和是所有采样值的总和。
样本数是聚合采样数（在本例中为 5）。
最小值是字节数/数据包数最低的采样值。
平均值是平均采样值，通过总和除以样本数计算得出。
最大值是字节数/数据包数最高的采样值。

平均吞吐量或 PPS 可以通过两种方式计算：

将总和除以周期（例如 300 秒）可得出简单的 5 分钟平均值。
将最大值除以 60 秒可得出活动最多的一分钟的平均值。

微爆如何反映在 CloudWatch 指标中

下面列举了一个微爆，并介绍了它如何反映在 CloudWatch 中：

该实例的网络带宽性能为 10 Gbps（1.25 GB/s）。
在某个给定的采样（60 秒）中，20 GB 的出站数据传输耗尽所有可用带宽，这导致 bw_out_allowance_exceeded 递增。传输将在大约 20 秒钟内完成，之后不再发送任何数据。
在剩余 4 个采样（240 秒）中，实例保持空闲状态。

在此示例中，5 分钟时段的平均吞吐量远低于微爆期间的平均吞吐量：

SUM(NetworkOut) / PERIOD = ((20 GB * 1 sample) + (0 GB * 4 samples)) / 300 seconds = ~0.066 GB/s * 8 bits = ~0.533 Gbps

即使根据最高采样值计算吞吐量，平均值仍不能反映吞吐量：

MAXIMUM(NetworkOut) / 60 = 20 GB / 60 seconds = ~0.333 GB/s * 8 bits = ~2.667 Gbps

监控微爆

要更精细地测量吞吐量和 PPS，可使用操作系统（OS）工具监控网络统计数据。在整形或活动较多的时段，更加频繁地监控网络统计数据。

下面列举了一些操作系统工具：

Linux

sar
nload
iftop
iptraf-ng

Windows

性能监视器

可以在 Linux 和 Windows 上使用 CloudWatch 代理将这些操作系统级别的网络指标作为自定义指标发布到 CloudWatch。这些指标的发布间隔可以低至 1 秒。请注意，高分辨率指标（时段小于 60 秒的指标）会导致费用增加。有关 CloudWatch 定价的详细信息，请参阅 Amazon CloudWatch 定价。

最佳做法是监控 ENA 提供的网络性能指标。驱动程序版本必须大于或等于 2.2.10（Linux）和 2.2.2（Windows），您才能查看指标。有关详细信息，请参阅以下内容：

监控 EC2 实例的网络性能（Linux）
监控 EC2 实例的网络性能（Windows）

CloudWatch 代理还可以发布 ENA 指标。有关发布 Linux 的 ENA 指标的说明，请参阅收集网络性能指标。对于 Windows，在性能监视器中提供 ENA 指标。您可以配置 CloudWatch 代理以发布性能监视器中提供的指标。

防止微爆

为了避免出现微爆，需要在发送方调整流量，使其不会超过最大吞吐量或数据包速率。这使得微爆难以避免。在发送方调整流量通常需要在应用程序级别进行更改。根据此更改的实施方式，可能需要操作系统支持调整流量并且在发送方启用此功能。但这可能并不总是能够实现或切实可行。在短时间内发送数据包的连接太多时也可能会导致发生微爆。在这种情况下，调整单个发送方无济于事。

最佳做法是监控 ENA 指标。如果经常达到限制，或者有证据表明流量整形影响了您的应用程序，请执行以下操作：

**纵向扩展：**转为使用更大的实例大小。实例越大，通常限额也越高。网络优化实例（带有“n”的实例，例如 C5n）的限额高于相应的非网络优化实例。
**横向扩展：**在多个实例之间分配流量，以减少单个实例上的流量和争用。

对于基于 Linux 的操作系统，除了上述选项外，还有适用于高级用户的缓解选项。您可以单独实施这些选项，也可以组合实施。最佳做法是在测试环境中对缓解措施进行基准测试，以验证这些缓解措施是否可以减少或消除流量整形，并且不会对工作负载产生负面影响。

**SO_MAX_PACING_RATE：**应用程序可以将此套接字选项传递给 setsockopt 系统调用，以指定最大调整速率（每秒字节数）。然后，Linux 内核会调整来自相应套接字的流量，使其不会超过限制。此选项需要以下各项：
应用程序代码级别的更改。
来自内核的支持。
使用公平队列（FQ）排队准则或内核支持在 TCP 层进行调整（仅适用于 TCP）。
**排队准则（qdiscs）：**qdiscs 负责数据包调度和可选的整形。有些 qdiscs（例如 fq）有助于消除来自单个流的流量突增。有关详细信息，请参阅流量控制（TC）手册页。
**浅层传输（Tx）队列：**在某些情况下，浅层 Tx 队列有助于减少 PPS 整形。这可以通过两种方式实现：
字节队列限制（BQL）：BQL 动态限制 Tx 队列中已发送但未确认的字节数。在 Linux 内核附带的 ENA 驱动程序版本（以“K”结尾的版本）上，BQL 默认处于启用状态。对于来自 GitHub 的 ENA 驱动程序版本（以“g”结尾的版本），自 v2.6.1g 起提供 BQL，并且 BQL 默认处于禁用状态。您可以使用 enable_bql ENA 模块参数启用 BQL。
**减小 Tx 队列长度：**将 Tx 队列长度从其默认的 1,024 个数据包减小到较低量（最少 256 个）。可以使用 ethtool 更改此长度。