

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 改善基於 Linux 的 EC2 執行個體的網路延遲
<a name="ena-improve-network-latency-linux"></a>

網路延遲是指資料封包從其來源傳送到目的地所需的時間。透過網路傳送資料的應用程式仰賴及時回應為使用者提供正面體驗。高網路延遲可能會導致各種問題，例如：
+ 網頁載入時間緩慢
+ 影片串流延遲
+ 難以存取線上資源

本節針對在 Linux 上執行的 Amazon EC2 執行個體，列出可改善網路延遲的步驟。若要達到最佳延遲，請依照下列步驟設定執行個體、核心和 ENA 驅動程式設定。如需其他設定指導方針，請參閱 GitHub 上[「ENA Linux 驅動程式最佳實務與效能最佳化指南」](https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/ena/ENA_Linux_Best_Practices.rst)。

**注意**  
視網路硬體、啟動執行個體的 AMI 以及應用程式使用案例而定，步驟和設定可能會略有不同。變更之前，請徹底測試並監控網路效能，確保可獲得理想結果。

## 減少資料封包的網絡跳轉次數
<a name="ena-latency-reduce-hops"></a>

資料封包在從路由器之間移動時所經過的每個躍點都會增加網路延遲。通常，流量必須經過多個躍點才能到達目的地。有兩種方法可以減少 Amazon EC2 執行個體經過的網路躍點：
+ **集群放置群組** – When 若指定[集群放置群組](placement-strategies.md#placement-groups-cluster)，Amazon EC2 會啟動彼此非常靠近的執行個體，其實際位置就在同一個可用區域 (AZ) 內，封裝更緊密。群組中執行個體的實體接近性可讓其充分利用高速連線，進而實現低延遲和高單流輸送量。
+ **專用執行個體**–[專用執行個體](dedicated-hosts-overview.md)是專供您使用的實體伺服器。使用專用執行個體，可以啟動執行個體在相同實體伺服器上執行。在相同專用執行個體上執行的執行個體之間的通訊可以不需要額外的躍點。

## Linux 核心組態如何影響延遲
<a name="ena-latency-kernel-config"></a>

Linux 核心組態可以增加或減少網路延遲。若要實現延遲最佳化目標，請務必根據工作負載的特定需求對 Linux 核心組態進行微調。

Linux 核心的許多組態選項可能有助於降低網路延遲。最具影響力的選項如下所示。
+ **啟用忙碌輪詢模式** — 忙碌輪詢模式可減少網路接收路徑的延遲。若啟用忙碌輪詢模式，通訊端層代碼可以直接輪詢網路裝置的接收佇列。忙碌輪詢的缺點是主機中的 CPU 使用率較高，因為要在緊密迴圈中輪詢新資料。有兩個全域設定可控制等待所有介面封包的微秒數。

     
`busy_read`  
通訊端讀取的低延遲忙碌輪詢逾時。這可控制等待通訊端層讀取裝置佇列上封包的微秒數。若要使用 **sysctl** 命令全域啟用此功能，Linux 核心組織建議使用 50 微秒的值。如需詳細資訊，請參閱 *Linux 核心使用者和管理員指南*中的 [busy\$1read](https://www.kernel.org/doc/html/v5.19/admin-guide/sysctl/net.html?highlight=busy_read)。  

  ```
  [ec2-user ~]$ sudo sysctl -w net.core.busy_read=50
  ```  
`busy_poll`  
輪詢和選取的低延遲忙碌輪詢逾時。這可控制等待事件的微秒數。建議值介於 50-100 微秒之間，具體取決於要輪詢的通訊端數目。新增的通訊端越多，數值越高。  

  ```
  [ec2-user ~]$ sudo sysctl -w net.core.busy_poll=50
  ```
+ **設定 CPU 電源狀態 (C-state)** – C-state 可控制核心未使用時要進入的休眠層級。建議您控制 C-state 來微調系統的延遲與效能。在更深層的 C-state 中，CPU 基本上處於「休眠」狀態，在喚醒並轉換回作用中狀態之前無法回應請求。核心進入休眠狀態需要時間，而且雖然休眠核心讓其他核心更有餘裕加速至更高頻率，但是欲喚醒該休眠核心並開始執行工作也需要時間。

  例如，若負責處理網路封包中斷的核心處於休眠狀態，則處理此類中斷的服務就可能受到延遲。您可以設定系統，使其不會使用更深層的 C-state。不過，雖然此組態可能會減少處理器反應延遲，但同時也減少了 Turbo Boost 的其他核心可用預留空間。

  若要減少處理器反應延遲，您可以限制更深層的 C-state。如需詳細資訊，請參閱「Amazon Linux 2 使用者指南」**中的[限制深層的 C-state 達到高效能與低延遲](https://docs.aws.amazon.com/linux/al2/ug/processor_state_control.html#c-states)。

## 插斷仲裁
<a name="ena-latency-interrupt-moderation"></a>

ENA 網路驅動程式可啟用執行個體與網路之間的通訊。驅動程式會處理網路封包，並將它們傳遞至網路堆疊或 Nitro 卡。網路封包傳入時，Nitro 卡會產生中斷，讓 CPU 通知軟體有事件發生。

插斷  
中斷是裝置或應用程式傳送給處理器的訊號。中斷會通知處理器已發生事件或已滿足需要立即注意的條件。中斷可以處理時間敏感任務，例如從網絡介面接收資料、處理硬體事件或服務來自其他裝置的請求。

插斷仲裁  
中斷調節是一種技術，可以透過彙總或延遲來減少裝置產生的中斷次數。中斷調節的目的是透過減少處理大量中斷所產生的額外負荷來改善系統效能。中斷次數過多會增加 CPU 使用率，對輸送量造成不利影響，而中斷次數太少會增加延遲。

動態中斷調節  
動態中斷調節是一種增強型的中斷調節形式，可根據目前的系統負載和流量模式動態調整中斷速率。其目標是在減少中斷負荷和每秒封包數或頻寬之間取得平衡。  
在某些 AMI 中預設啟用動態中斷調節 (但在所有 AMI 中都可啟用或停用)。

為了將網路延遲降到最低，可能需要停用中斷調節。但是這也可能會增加插斷處理的開銷。在減少延遲和盡可能減少開銷之間找到適當的平衡點非常重要。`ethtool` 命令可協助您設定插斷仲裁。依預設，`rx-usecs` 設定為 `20`，`tx-usecs` 設定為 `64`。

若要取得目前的插斷仲裁設定，請使用下列命令。

```
[ec2-user ~]$ ethtool -c interface | egrep "rx-usecs:|tx-usecs:|Adaptive RX"
Adaptive RX: on  TX: off
rx-usecs: 20
tx-usecs: 64
```

若要停用中斷修改和動態中斷調節，請使用下列命令。

```
[ec2-user ~]$ sudo ethtool -C interface adaptive-rx off rx-usecs 0 tx-usecs 0
```