Die Netzwerkleistung in EC2-Windows-Instances optimieren - Amazon Elastic Compute Cloud

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die Netzwerkleistung in EC2-Windows-Instances optimieren

Um die maximale Netzwerkleistung auf Ihren Windows-Instances mit erweitertem Netzwerk zu erreichen, müssen Sie möglicherweise die Standardkonfiguration des Betriebssystems ändern. Wir empfehlen die folgenden Konfigurationsänderungen für Anwendungen, die eine hohe Netzwerkleistung erfordern. Andere Optimierungen (wie zum Beispiel das Einschalten der Prüfsummenentladung und das Aktivieren von RSS) sind bereits in offiziellen Windows-AMIs konfiguriert.

Anmerkung

TCP-Chimney-Verschiebung sollte in den meisten Anwendungsfällen deaktiviert werden und ist ab Windows Server 2016 veraltet.

Zusätzlich zu diesen Betriebssystemoptimierungen sollten Sie auch die Maximum Transmission Unit (MTU, maximale Übertragungseinheit) Ihres Netzwerkverkehrs berücksichtigen und an Ihren Workload und Ihre Netzwerkarchitektur anpassen. Weitere Informationen finden Sie unter Netzwerk-MTU (Maximum Transmission Unit) für Ihre EC2-Instance.

AWS misst regelmäßig die durchschnittlichen Umlauflatenzen zwischen den Instances, die in einer Cluster Placement-Gruppe von 50us gestartet werden, und Tail-Latenzen von 200us beim Perzentil 99,9. Wenn Ihre Anwendungen konsistent niedrige Latenzen erfordern, empfehlen wir, die neueste Version der ENA-Treiber auf Instances mit fester Leistung, die auf dem Nitro-System basieren.

Konfiguration der CPU-Affinität für empfangsseitige Skalierung

Empfangsseitige Skalierung (RSS, Receive Side Scaling) wird verwendet, um die CPU-Auslastung von Netzwerkverkehr auf mehrere Prozessoren zu verteilen. Standardmäßig ist für die offiziellen Amazon Windows-AMIs RSS aktiviert. ENA-Elastic-Network-Interfaces stellen bis zu acht RSS-Warteschlangen bereit. Durch das Definieren der CPU-Affinität für RSS-Warteschlangen und andere Systemprozesse lässt sich die CPU-Auslastung auf Multi-Core-Systeme verteilen, wodurch mehr Netzwerkverkehr verarbeitet werden kann. Bei Instances mit mehr als 16 vCPUs wird empfohlen, das Set-NetAdapterRSS-PowerShell-Cmdlet zu verwenden, das den Boot-Prozessor (logischer Prozessor 0 und 1, wenn Hyper-Threading aktiviert ist) manuell von der RSS-Konfiguration für alle elastischen Netzwerkschnittstellen ausschließt, um eine Konkurrenzsituation mit verschiedenen Systemkomponenten zu vermeiden.

Windows ist hyper-thread-fähig und sorgt dafür, dass die RSS-Warteschlangen einer einzelnen Netzwerkkarte (NIC) immer auf verschiedenen physischen Kernen platziert werden. Sofern Hyper-Threading nicht deaktiviert ist, sollten Sie die RSS-Konfiguration jeder NIC auf einen Bereich von 16 logischen Prozessoren verteilen, um Konflikte unter anderen NICs vollständig zu vermeiden. Mit dem Set-NetAdapterRss-Cmdlet können Sie für jede NIC einen Bereich von gültigen logischen Prozessoren definieren, indem Sie die Werte von „BaseProcessorGroup“, „BaseProcessorNumber“, „MaxProcessingGroup“, „MaxProcessorNumber“ und „NumaNode“ (optional) festlegen. Wenn es nicht genügend physische Kerne gibt, um Konflikte zwischen NICs vollkommen zu beseitigen, sollten Sie die überlappenden Bereiche minimieren oder die Anzahl der logischen Prozessoren in den ENI-Bereichen abhängig von den voraussichtlichen Workload der ENI reduzieren (das heißt, ggf. müssen einer Administrator-Netzwerk-ENI mit geringem Volumen nicht so viele RSS-Warteschlangen zugewiesen werden). Zudem müssen, wie zuvor erwähnt, verschiedene Komponenten in der CPU 0 ausgeführt werden. Daher wird empfohlen, sie aus allen RSS-Konfigurationen auszuschließen, wenn genügend vCPUs verfügbar sind.

Wenn beispielsweise drei elastische Netzwerkschnittstellen auf einer Instance mit 72 vCPUs und 2 NUMA-Knoten mit aktiviertem Hyperthreading bestehen, verteilen die folgenden Befehle die Netzwerklast auf die beiden CPUs ohne Überlappung und verhindern die Nutzung von Kern 0 vollständig.

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

Beachten Sie, dass diese Einstellungen für jeden Netzwerkadapter bestehen bleiben. Wenn die Größe einer Instance geändert wird und die Instance danach eine andere Anzahl von vCPUs hat, sollten Sie die RSS-Konfiguration für jede aktivierte elastische Netzwerkschnittstelle erneut auswerten. Die vollständige Microsoft-Dokumentation für das cmdlet finden Sie hier: Set-NetAdapterRss.

Besonderer Hinweis für SQL-Workloads: Wir empfehlen auch, die E/A-Thread-Affinitätseinstellungen zusammen mit Ihrer RSS-Konfiguration der elastischen Netzwerkschnittstelle zu prüfen, um E/A- und Netzwerkkonflikte für dieselben CPUs zu minimieren. Weitere Informationen finden Sie unter Serverkonfiguration: Affinitätsmaske.