為什麼當平均使用率較低時，我的 Amazon EC2 執行個體會超出其網路限制？

簡短描述

即使平均使用率較低，bw_in_allowance_exceeded、bw_out_allowance_exceeded 或 pps_allowance_exceeded 彈性網路介面卡 (ENA) 網路效能指標也可能會增加。導致此問題最常見的原因是網路資源需求出現短暫高峰，這稱為微型爆量。微型爆量通常只會持續幾秒、幾毫秒，甚至幾微秒。而 Amazon CloudWatch 指標不夠詳細，無法反映這些情況。例如，您可以使用 CloudWatch 中的 NetworkIn 和 NetworkOut 執行個體指標來計算每秒的平均輸送量。但是，由於微型爆量，計算出的速率可能低於該執行個體類型的可用執行個體頻寬。

在具有「高達」頻寬的較小執行個體上 (例如「每秒高達 10 千兆位元 (Gbps)」)，bw_in_allowance_exceeded 和 bw_out_allowance_exceeded 指標也會增加。 較小的執行個體會使用網路 I/O 點數，在有限時間內超越其基準頻寬。當點數耗盡時，流量會與基準頻寬保持一致，且指標會增加。由於執行個體爆量是以最佳努力原則進行，因此即使您的執行個體具有可用的 I/O 點數，指標也可能會增加。

當非最佳流量模式導致較低 PPS 速率下的封包遺失時，pps_allowance_exceeded 指標也會增加。不對稱路由、過時的驅動程式、小型封包、片段和連接追蹤會影響工作負載的 PPS 效能。

解決方法

平均值計算

CloudWatch 每 60 秒對 Amazon EC2 指標進行取樣，以擷取 1 分鐘內傳輸的總位元組或封包。Amazon EC2 會彙總樣本，並以 5 分鐘為週期發佈到 CloudWatch。該期間的每個統計資料都會顯示不同的值。

當您使用詳細監控時，CloudWatch 會以 1 分鐘為週期發佈 NetworkIn 和 NetworkOut 指標，並且不進行彙總。Sum、Minimum、Average 和 Maximum 的值相同，SampleCount 的值為 1。CloudWatch 始終會以 5 分鐘為週期，彙總並發佈 NetworkPacketsIn 和 NetworkPacketsOut 指標。

使用以下方法計算一段時間內的平均輸送量 (以每秒位元組 (Bps) 或 PPS 為單位)：

• 若要計算指定時間段內的簡單平均值，請將 Sum (總和) 除以 Period (週期)，或除以數值之間的時間戳記差 (DIFF_TIME)。
• 若要獲得最頻繁活動的一分鐘平均值，請將 Maximum (最大值) 除以 60 秒。

若要將 Bps 轉換為 Gbps，請將計算結果除以 1,000,000,000 位元組，然後乘以 8 位元。

CloudWatch 指標中的微型爆量

以下範例顯示了微型爆量在 CloudWatch 中的出現方式。此執行個體的網路頻寬配額為 10 Gbps，並使用基本監控。

在 60 秒的樣本中，大約 24 GB 的傳出資料傳輸使用了所有可用頻寬。資料傳輸增加了 bw_out_allowance_exceeded 值，並以平均速度 9.6 Gbps 在大約20秒內完成。Amazon EC2 不會傳送任何其他資料，且該執行個體在剩餘的 4 個 240 秒樣本期間保持閒置狀態。

5 分鐘內的平均輸送量 (Gbps) 遠低於微型爆量期間的輸送量：

公式： AVERAGE_Gbps = SUM(NetworkOut) / PERIOD(NetworkOut) / 1,000,000,000 位元組* 8 位元

SUM(NetworkOut) = (~24 GB * 1 個樣本) + (~0 GB * 4 個樣本) = ~24 GB

PERIOD(NetworkOut) = 300 秒 (5 分鐘)

AVERAGE_Gbps = ~24 / 300 / 1,000,000,000 * 8 = ~0.64 Gbps

即使根據最高樣本計算平均輸送量，該數量仍無法反映微型爆量期間的輸送量：

公式： AVERAGE_Gbps = MAXIMUM(NetworkOut) / 60 seconds / 1,000,000,000 位元組 / 8 位元

MAXIMUM(NetworkOut) = ~24 GB

AVERAGE_Gbps = ~24 GB / 60 / 1,000,000,000 * 8 = ~3.2 Gbps

當有高解析度資料時，您可以獲得更準確的平均值。當您以 1 秒的間隔收集作業系統 (OS) 網路使用情況指標時，平均輸送量短暫達到約 9.6 Gbps。

監控微型爆量

您可以使用 Linux 和 Windows 上的 CloudWatch 代理程式，以最多 1 秒的間隔將作業系統層級網路指標發佈到 CloudWatch。該代理程式還可以發佈 ENA 網路效能指標。

注意：高解析度指標的定價更高。

您也可以使用 OS 工具，以最多 1 秒的間隔監控網路統計資料。如果是 Windows 執行個體，請使用效能監視器。如果是 Linux，請使用 sar、nload、iftop、iptraf-ng 或 netqtop。

為了清楚地識別微型爆量，請執行作業系統的封包擷取，然後使用 Wireshark 以 1 毫秒的間隔繪製 I/O 圖表。如需詳細資訊，請參閱下載 Wireshark 和 8.8。Wireshark 網站上的「I/O 圖表」視窗。

此方法具有以下限制：

• 網路配額大約與微秒等級成比例。例如，具有 10 Gbps 頻寬效能的執行個體類型可以在 1 毫秒內傳送和接收大約 10 兆位元 (Mb)。
• 封包擷取會導致額外的系統負載，並可能降低整體輸送量和 PPS 速率。
• 由於緩衝區已滿導致封包遺失，封包擷取可能未包含所有封包。
• 時間戳記無法準確反映網路何時傳送封包或 ENA 何時接收封包。
• I/O 圖表可能顯示傳入流量的活動較低，因為 Amazon EC2 會在流量達到執行個體之前，對超出配額的流量進行流量重塑。

封包排入佇列和遺失

當網路將封包排入佇列時，產生的延遲以毫秒為單位。TCP 連線可以擴展其輸送量，並超出 EC2 執行個體類型的配額。因此，即使使用瓶頸頻寬和往返 (BBR) 或其他使用延遲作為訊號的擁塞控制演算法，也預期會出現某些封包排入佇列。當網路遺失封包時，TCP 會自動重新傳輸遺失的區段。封包排入佇列和遺失都可能導致更高的延遲和更低的輸送量。但是，您無法查看復原動作。通常，只有當您的應用程式使用較短的逾時設定，或者當網路遺失夠多的封包而導致連線強制關閉時，才會看到錯誤。

ENA 網路效能指標不會區分已排入佇列的封包和已遺失的封包。若要測量 Linux 上的連線層級 TCP 延遲，請使用 ss 或 tcprtt 命令。若要測量 TCP 重新傳輸，請使用 ss 或 tcpretrans 命令取得連接層級統計資料，並使用 nstat 取得系統範圍統計資料。若要下載 BPF Compiler Collection (BCC) 中的 tcprtt 和 tcpretrans 工具，請參閱 GitHub 網站上的 bcc。您也可以使用封包擷取來測量延遲和重新傳輸。

**注意：**由於超出執行個體配額而導致網路遺失的封包不會出現在 ip 或 ifconfig 的遺失計數器中。

防止微型爆量

首先，根據應用程式的關鍵效能指標 (KPI) 檢查 ENA 網路效能指標，以確定封包排入佇列或遺失的影響。

如果 KPI 低於所需閾值，或您收到應用程式日誌錯誤，請執行以下動作以減少包排入佇列或遺失：

• 向上擴展： 將執行個體大小增加到具有更高網路配額的執行個體。帶有「n」的執行個體類型 (例如 C7gn) 具有更高的網路配額。
• 橫向擴充： 將流量分散到多個執行個體，以減少單一執行個體的流量和爭用。

如果是以 Linux 為基礎的動作，您也可以實作以下策略來避免微型爆量。最佳做法是在測試環境中測試這些策略，以確認它們是否能減少流量重塑，且不會對工作負載產生負面影響。

**注意：**以下策略僅適用於傳出流量。

SO_MAX_PACING_RATE

使用 SO_MAX_PACING_RATE 通訊端選項來指定連線的最大佇列控制速率 (以 Bps 計算)。然後，Linux 核心會在來自通訊端的封包之間引入延遲，以確保輸送量不超過您指定的配額。

若要使用此方法，您必須實作以下變更：

• 應用程式程式碼變更。
• 來自內核的支援。如需詳細資訊，請參閱 GitHub 網站上的 net:introduce SO_MAX_PACING_RATE。
• 公平佇列 (FQ) 排入佇列規則或核心對 TCP 層佇列控制的支援 (僅適用於 TCP)。

如需詳細資訊，請參閱 man7 網站上的 getsockopt(2) - Linux 手冊頁和 tc-fq(8) - Linux 手冊頁。另請參閱 GitHub 網站上的 tcp：內部節奏控制的實作。

qdiscs

Linux 使用每個 ENA 佇列的 pfifo_fast 排入佇列規則 (qdisc) 的預設組態來排程封包。使用 fq qdisc 來減少單一流程的流量爆量，並調節其輸送量。或者，使用 fq_codel 和 cake 提供主動式佇列管理 (AQM) 功能，以減少網路擁塞並改善延遲。如需詳細資訊，請參閱 man7 網站上的 tc(8) - Linux 手冊頁。

如果是 TCP，請在用戶端和伺服器上啟動明確擁塞通知 (ECN)。然後，將 ECN 與可以執行 ECN 擁塞體驗 (CE) 標記的 qdisc 結合使用。CE 標記會導致作業系統降低連線的輸送量，以減少超出執行個體配額所造成的延遲和封包遺失。若要使用此解決方案，您必須根據連線的平均往返時間 (RTT) 設定具有低 CE 閾值的 qdisc。最佳做法是僅在連線之間的平均 RTT 差異不大時，才使用此解決方案。例如，您的執行個體僅在一個可用區域中管理流量。

由於效能問題，在執行個體層級設定彙總頻寬重塑並不是最佳做法。

淺層傳輸 (Tx) 佇列

使用淺層 Tx 佇列來減少 PPS 重塑。位元組佇列限制 (BQL) 會動態限制 Tx 佇列中的傳輸位元組。若要啟動 BQL，請將 ena.enable_bql=1 新增至 GRUB 中的核心命令列。

**注意：**您必須擁有 ENA 驅動程式 2.6.1g 版或更新版本，才能使用此解決方案。BQL 已在使用 Linux 核心版本 (以 K 結尾) 的 ENA 驅動程式上啟用。

如需詳細資訊，請參閱 LWN.net 網站上的 bql： 位元組佇列限制。

當您使用 ENA Express 時，必須停用 BQL 以最大化頻寬。

您也可以使用 ethtool，將 Tx 佇列長度從預設的 1,024 個封包減少。如需詳細資訊，請參閱 man7 網站上的 ethtool(8) - Linux 手冊頁。

相關資訊

Amazon EC2 執行個體網路頻寬