View a markdown version of this page

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 Roundtrip-Latenzen zwischen Instances, die in einer Cluster-Platzierungsgruppe von 50 us gestartet wurden, und die Tail-Latenzen von 200 us im Perzentil von 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 Instanztypen mit mehr als 16 vCPUs wird empfohlen, das Set-NetAdapterRSS PowerShell Cmdlet zu verwenden, das den Startprozessor (logischer Prozessor 0 und 1, wenn Hyper-Threading aktiviert ist) manuell von der RSS-Konfiguration für alle Elastic Network-Schnittstellen ausschließt, um Konflikte 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. Um Konflikte mit anderen Netzwerkkarten vollständig zu vermeiden, sollten Sie daher die RSS-Konfiguration jeder Netzwerkkarte auf einen Bereich von 16 logischen Prozessoren verteilen, sofern Hyperthreading nicht deaktiviert ist. Mit dem Set-NetAdapterRss Cmdlet können Sie den Bereich gültiger logischer Prozessoren pro NIC definieren, indem Sie die Werte von BaseProcessorGroup,, BaseProcessorNumber und (optional) definieren. MaxProcessingGroup MaxProcessorNumber NumaNode 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 außerdem, dass Sie Ihre I/O Thread-Affinitätseinstellungen zusammen mit Ihrer RSS-Konfiguration für die Elastic Network-Schnittstelle überprüfen, um Netzwerkkonflikte für dieselben CPUs zu minimieren I/O . Weitere Informationen finden Sie unter Serverkonfiguration: Affinitätsmaske.