作業系統最佳化

為了在執行個體上達到使用增強型聯網的最大網路效能，您可能需要修改預設的作業系統組態。建議您針對需要高網路效能的應用程式進行下列組態變更。其他最佳化 (例如開啟檢查總和卸載和啟用 RSS) 已經在官方 Windows AMI 上執行。

注意

大多數使用案例都應該停用 TCP 煙囪卸載；此功能在 Windows Server 2016 中已被移除。

除了這些作業系統最佳化以外，您也應該考慮網路流量的最大傳輸單位 (MTU)，並根據您的工作負載和網路架構來調整。如需詳細資訊，請參閱 EC2 執行個體的網路最大傳輸單位 (MTU)。

AWS 定期測量在 50us 叢集置放群組中啟動的執行個體之間的平均往返延遲，以及 99.9 百分位數為 200us 的尾部延遲。如果您的應用程式需要始終很低的延遲，我們建議在 Nitro 系統中建構的固定效能執行個體上使用最新版本的 ENA 驅動程式。

設定 RSS CPU 親和性

接收端調整 (RSS) 可用來將網路流量 CPU 負載分配至多個處理器。根據預設，Amazon 官方 Windows AMI 會設為啟用 RSS。ENA ENI 最多提供 8 個 RSS 佇列。藉由為 RSS 佇列以及其他系統處理程序定義 CPU 親和性，您可以將 CPU 負載分配至多核心系統，以便處理更多網路流量。對於擁有超過 16 個 vCPUs 的執行個體類型，建議您使用Set-NetAdapterRSS PowerShell 指令程式，該指令程式會從所有 ENI 的 RSS 組態中手動排除開機處理器 (啟用超執行緒時，邏輯處理器 0 和 1)，以避免與各種系統元件發生爭用。

Windows 會察覺超執行緒，並確保單一 NIC 的 RSS 佇列總是置於不同的實體核心。因此，除非停用超執行緒，否則為了完全避免與 NIC 競爭，會將各 NIC 的 RSS 組態分配在 16 個邏輯處理器之間。指Set-NetAdapterRss令程式可讓您定義 BaseProcessorGroup、 BaseProcessorNumber、、和 NumaNode (選用) 的值，以定義每個 NIC 範圍的有效邏輯處理器。 MaxProcessingGroup MaxProcessorNumber如果無足夠的實體核心可以完全消除 NIC 間的競爭，視 ENI 預期的工作負載而定，請盡量減少重疊範圍，或減少 ENI 範圍中的邏輯處理器數量 (換言之，少量管理網路 ENI 可能不需要許多已指派的 RSS 佇列)。此外，如先前所述，各種元件必須在 CPU 0 上執行，因此當可使用足夠的 vCPU 時，我們建議從所有 RSS 組態中加以排除。

例如，當有 2 個 NUMA 節點並啟用超執行緒的 72 vCPU 執行個體出現三個 ENI 時，下列命令會將網路負載分配在兩顆 CPU 之間，而不會重疊並避免完全使用核心 0。

Set-NetAdapterRss -Name NIC1 -BaseProcessorGroup 0 -BaseProcessorNumber 2 -MaxProcessorNumber 16 
Set-NetAdapterRss -Name NIC2 -BaseProcessorGroup 1 -BaseProcessorNumber 0 -MaxProcessorNumber 14 
Set-NetAdapterRss -Name NIC3 -BaseProcessorGroup 1 -BaseProcessorNumber 16 -MaxProcessorNumber 30 

注意，這些設定對於每個網路轉接器都是持續有效。如果有個執行個體調整大小成不同 vCPU 數的執行個體，您應針對每個已啟用 ENI 重新評估 RSS 組態。您可於以下網站找到 Set-NetAdapterRss cmdlet 完整的 Microsoft 文件：https://docs.microsoft.com/en-us/powershell/module/netadapter/set-netadapterrss。

SQL 工作負載的特別注意事項：我們還建議您檢查輸入/輸出執行緒同質性設定和 ENI RSS 組態，以盡量減少相同 CPU 的輸入/輸出和網路爭用。請參閱 親和性遮罩伺服器組態選項。