為什麼我的 EC2 執行個體在平均使用率較低時超出其網路限制?

上次更新日期:2022 年 8 月 4 日

為什麼我的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體在平均使用率較低時超出其網路限制?

簡短描述

針對支援增強型網路功能的執行個體,您可透過彈性網路介面卡 (ENA) 即時查詢網路效能指標。自從上一次重設裝置之後,會透過這些指標顯示每個網路介面排入佇列或捨棄的累計封包數。以下是部分 ENA 指標:

  • bw_in_allowance_exceeded:由於輸入彙總頻寬超過執行個體上限而排入佇列或捨棄的封包數。
  • bw_out_allowance_exceeded:由於傳出彙總頻寬超過執行個體上限而排入佇列或捨棄的封包數。
  • pps_allowance_exceeded:由於每秒雙向封包 (PPS) 超過執行個體上限而排入佇列或捨棄的封包數。

網路效能規格會根據執行個體類型而有所不同。若要檢視規格,請參閱目前世代的執行個體。 即使您在 Amazon CloudWatch 看到的平均頻寬或 PPS 很低,您有時仍可能會看到排入佇列或捨棄的情況。例如,CloudWatch 的下列指標:NetworkInNetworkOutNetworkPacketsInNetworkPacketsOut 可能會顯示數目,但這不代表已經達到上限。

解析度

前述狀況最常見的原因是微爆。微爆是指需求短暫暴增,隨後活動量降低或無活動量。這些暴增通常僅持續數秒、毫秒甚至微秒。上一節列出的 CloudWatch 指標不夠精細,無法反映微爆的情況。

如何計算平均值

上一節列出的 CloudWatch EC2 指標每分鐘取樣一次。這些指標擷取此期間內傳輸的總位元組或封包數。然後,每隔 5 分鐘,會彙總這些樣本並傳送到 CloudWatch。這個時段内的每個統計數字都會傳回不同的樣本值:

  • Sum 指所有樣本值的總和。
  • SampleCount 指彙總樣本的數量 (這個例子為 5)。
  • Minimum 指最低位元組 / 封包數的樣本值。
  • Average 指平均樣本值,由 Sum 除以 SampleCount 得出。
  • Maximum 指最高位元組 / 封包數的樣本值。

平均輸送量或 PPS 有兩種計算方式:

  • 總和除以時段 (例如 300 秒),即可得到簡單的 5 分鐘平均值。
  • 最大值除以 60 秒,計算活動量最高那一分鐘的平均值。

CloudWatch 指標如何反映微爆

以下是微爆的範例,以及如何在 CloudWatch 中反映:

  • 執行個體的網路頻寬效能為每秒 10 Gbps (每秒 1.25 GB)。
  • 在指定樣本 (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) 或更高版本。如需更多資訊,請參閱 LinuxWindows 的相關頁面。

CloudWatch 代理程式也可傳送 ENA 指標。如需指示了解 Linux 傳送的 ENA 指標,請參閱收集網路效能指標。可從效能監視器獲得 Windows 的 ENA 指標,而 CloudWatch 代理程式可設定向 Windows 傳送任何可用指標。

避免微爆

為了避免出現微爆,傳送者必須調節流量,以防超過最大輸送量或封包速率。這令微爆難以避免。傳送者若要調節流量,通常需要應用程式層級的變更。根據變更的執行方式,傳送者可能需要提供並開啟作業系統才能調節流量。這並不總是可行,有時甚至不可能。若在短時間內傳送封包的連線太多,也可能發生微型爆量。發生這種情況時,調節單一發送者並無幫助。

由於這些原因,監視 ENA 指標乃是最佳實務。如果經常達到極限,或者有證據顯示流量塑造影響了您的應用程式,請遵循下列指示:

  • 縱向擴展:移至較大的執行個體。較大的執行個體通常有著更高的限額。網路最佳化執行個體 (例如包含「n」,如 C5n) 的限額高於其對應的非網路最佳化執行個體。
  • 橫向擴展:將流量分散到多個執行個體,降低個別執行個體的流量及競爭。

針對 Linux,除了上述選項之外,進階使用者還有可能的風險降低選項。您可以單獨或合併實作這些選項。最佳實務是在測試環境中對緩和措施進行基準測試,以確認措施是否減少或消除流量塑造,而不會對工作負載造成不利影響。

  • SO_MAX_PACING_RATE:可透過應用程式將此通訊端選項傳送給 setsockopt 系統呼叫,來指定最大調節率 (每秒位元組數)。然後,Linux 核心會調節通訊端流量,使其不超過限制。此選項需要執行下列操作:
  • 佇列規則 (qdiscs):qdiscs 負責封包排程及可選塑造。有些 qdiscs (例如 fq) 有助於消除個別流量中的流量激增。如需詳細資訊,請參閱流量控制 (TC) 手冊頁面。
  • 淺層傳輸 (Tx) 佇列:在部分情況下,淺層 Tx 佇列可降低 PPS 塑造。這可透過兩種方式完成:
    • 位元組佇列限制 (BQL):BQL 動態限制 Tx 佇列在執行中的位元組數量。Linux 核心隨附的 ENA 驅動程式版本 (以「K」結尾的版本) 預設為開啟 BQL。GitHub 的 ENA 驅動程式版本 (以「g」結尾的版本) 從 v2.6.1g 起提供 BQL 並預設為關閉。您可利用 enable_bql ENA 單元參數來開啟 BQL。
    • 降低 Tx 佇列長度:把 Tx 佇列長度從預設的 1,024 個封包減少到較低數量 (最少 256 個)。您可利用 ethtool 來變更長度。

此文章是否有幫助?


您是否需要帳單或技術支援?