Optimisation des performances réseau sur les instances EC2 Windows - Amazon Elastic Compute Cloud

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Optimisation des performances réseau sur les instances EC2 Windows

Pour optimiser les performances réseau de vos instances Windows grâce à une mise en réseau améliorée, vous devrez peut-être modifier la configuration par défaut du système d'exploitation. Nous recommandons les modifications de configuration suivantes pour les applications nécessitant des performances réseau élevées. D'autres optimisations (telles que l'activation du déchargement par checksum et son activationRSS, par exemple) sont déjà configurées sur Windows officiel. AMIs

Note

TCPle déchargement par cheminée doit être désactivé dans la plupart des cas d'utilisation et est devenu obsolète depuis Windows Server 2016.

Outre ces optimisations du système d'exploitation, vous devez également prendre en compte l'unité de transmission maximale (MTU) de votre trafic réseau et l'ajuster en fonction de votre charge de travail et de votre architecture réseau. Pour plus d’informations, consultez Unité de transmission maximale du réseau (MTU) pour votre EC2 instance.

AWS mesure régulièrement les latences aller-retour moyennes entre les instances lancées dans un groupe de placement en cluster de 50 µs et les latences finales de 200 µs au 99,9 centile. Si vos applications nécessitent des latences constamment faibles, nous vous recommandons d'utiliser la dernière version des ENA pilotes sur les instances à performances fixes basées sur le système Nitro.

Configurer l'CPUaffinité de dimensionnement côté réception

Le dimensionnement côté réception (RSS) est utilisé pour répartir la CPU charge du trafic réseau entre plusieurs processeurs. Par défaut, les versions officielles d'Amazon Windows AMIs sont configurées avec RSS Activé. ENAles interfaces réseau élastiques fournissent jusqu'à huit RSS files d'attente. En définissant l'CPUaffinité pour les RSS files d'attente, ainsi que pour les autres processus du système, il est possible de répartir la CPU charge sur les systèmes multicœurs, ce qui permet de traiter davantage de trafic réseau. Pour les types d'instances comportant plus de 16vCPUs, nous vous recommandons d'utiliser l'Set-NetAdapterRSS PowerShell applet de commande, qui exclut manuellement le processeur de démarrage (processeurs logiques 0 et 1 lorsque l'hyperthreading est activé) de la RSS configuration de toutes les interfaces réseau Elastic, afin d'éviter tout conflit avec les différents composants du système.

Windows est sensible à l'hyperthread et veille à ce que les RSS files d'attente d'une seule carte d'interface réseau (NIC) soient toujours placées sur des cœurs physiques différents. Par conséquent, à moins que l'hyperthreading ne soit désactivé, afin d'éviter tout conflit avec d'autres processeursNICs, répartissez la RSS configuration de chacun NIC sur une gamme de 16 processeurs logiques. L'Set-NetAdapterRssapplet de commande vous permet de définir par NIC plage de processeurs logiques valides en définissant les valeurs de BaseProcessorGroup,, BaseProcessorNumber MaxProcessingGroup MaxProcessorNumber, et NumaNode (facultatif). S'il n'y a pas suffisamment de cœurs physiques pour éliminer complètement les interférences, minimiser les plages qui se chevauchent ou réduire le nombre de processeurs logiques dans les plages d'Elastic Network Interface en fonction de la charge de travail attendue de l'interface (en d'autres termes, une interface réseau administrative à faible volume peut ne pas avoir besoin d'autant de RSS files d'attente assignées). NIC En outre, comme indiqué précédemment, divers composants doivent fonctionner sur CPU 0. Nous vous recommandons donc de l'exclure de toutes les RSS configurations lorsque suffisamment de composants vCPUs sont disponibles.

Par exemple, lorsqu'il existe trois interfaces réseau élastiques sur une CPU instance 72 v avec 2 NUMA nœuds avec l'hyperthreading activé, les commandes suivantes répartissent la charge réseau entre les deux CPUs sans chevauchement et empêchent complètement l'utilisation du noyau 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

Notez que ces paramètres sont persistants pour chaque adaptateur réseau. Si une instance est redimensionnée avec un nombre différent devCPUs, vous devez réévaluer la RSS configuration pour chaque interface Elastic network activée. La documentation Microsoft complète relative à l'Set-NetAdapterRssapplet de commande se trouve ici : powershell/module/netadapter/set-netadapterrsshttps://docs.microsoft.com/en-us/.

Remarque spéciale concernant les SQL charges de travail : nous vous recommandons également de revoir vos paramètres d'affinité des threads d'E/S ainsi que la RSS configuration de votre interface Elastic Network afin de minimiser les interférences entre les E/S et le réseau. CPUs Consultez Option de configuration de serveur de masque d’affinité.