Réglage des performances des cartes réseau
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI versions 21H2 et 20H2
Utilisez les informations de cette rubrique pour optimiser les cartes réseau de performances pour les ordinateurs qui exécutent Windows Server 2016 et versions ultérieures. Si vos cartes réseau fournissent des options de paramétrage, vous pouvez utiliser ces options pour optimiser le débit réseau et l’utilisation des ressources.
Les variables suivantes déterminent les paramètres de réglage adéquats de vos adaptateurs réseau :
- La carte réseau et son jeu de fonctionnalités
- Le type de charge de travail que le serveur réalise
- Les ressources matérielles et logicielles du serveur
- Vos objectifs de performances pour le serveur
Les sections qui suivent décrivent certaines options de réglage des performances.
Activation des fonctionnalités de déchargement
L'activation des fonctionnalités de déchargement de la carte réseau est souvent bénéfique. Toutefois, l’adaptateur réseau n'est pas toujours suffisamment puissant pour gérer les capacités de déchargement lorsque le débit est élevé.
Important
N’utilisez pas les fonctionnalités de déchargement IPsec Task Offload ou TCP Chimney Offload. Ces technologies sont déconseillées dans Windows Server 2016 et peuvent nuire aux performances du serveur et du réseau. En outre, ces technologies risquent de ne pas être prises en charge par Microsoft à l’avenir.
Par exemple, considérez une carte réseau qui a des ressources matérielles limitées. Dans ce cas, l’activation des fonctionnalités de déchargement de segmentation peut réduire le débit maximal durable de l’adaptateur. Toutefois, si le débit réduit est acceptable, vous devez activer les fonctionnalités de déchargement de segmentation.
Notes
Certains adaptateurs réseau exigent que vous activiez les fonctionnalités de déchargement indépendamment pour les chemins d’envoi et de réception.
Activation du partage du trafic entrant (RSS) pour les serveurs web
RSS peut améliorer l'extensibilité web et les performances lorsque le serveur comprend moins de cartes réseau que de processeurs logiques. Lorsque l'ensemble du trafic web passe par les adaptateurs réseau, le serveur peut prendre en charge les demandes web entrantes provenant de connexions différentes peuvent être traitées simultanément dans différents processeurs.
Important
Évitez d’utiliser des adaptateurs réseau non RSS et des adaptateurs réseau compatibles RSS sur le même serveur. En raison de la logique de distribution de charge dans RSS et du protocole HTTP (Hypertext Transfer Protocol), les performances peuvent être fortement dégradées si un adaptateur réseau ne prenant pas en charge RSS accepte le trafic sur un serveur équipé d’une ou plusieurs adaptateurs réseau prenant en charge RSS. Dans cette situation, vous devez utiliser les cartes prenant en charge RSS ou désactiver RSS sous l'onglet Propriétés avancées dans les propriétés de la carte réseau.
Pour déterminer si une carte réseau prend en charge RSS, vous pouvez consulter l'onglet Propriétés avancées dans les propriétés de la carte réseau.
Profils RSS et Files d'attente RSS
Le profil RSS prédéfini par défaut est NUMAStatic, qui diffère de la valeur par défaut utilisée par les versions précédentes de Windows. Avant de commencer à utiliser les profils RSS, passez en revue les profils existants pour comprendre quand ils sont bénéfiques et comment ils s'appliquent à votre environnement et matériel réseau.
Par exemple, si en ouvrant le Gestionnaire des tâches et en passant en revue les processeurs logiques de votre serveur, il vous semble que ces derniers sont sous-utilisés pour le trafic de réception, vous pouvez essayer de passer le nombre de files d'attente de deux au maximum que votre adaptateur réseau prend en charge. Votre carte réseau peut proposer des options permettant de changer le nombre de files d'attente RSS dans le pilote.
Augmentation des ressources des adaptateurs réseau
Pour les adaptateurs réseau qui autorisent la configuration manuelle des ressources, comme les tampons de réception et d'envoi, vous devez augmenter les ressources allouées.
Certaines cartes réseau définissent des tampons de réception faibles afin de conserver la mémoire allouée depuis l'hôte. Cela conduit à des paquets ignorés et des performances réduites. Par conséquent, dans les scénarios de réception intensive, nous vous recommandons d'augmenter la valeur du tampon de réception à son maximum.
Remarque
Si un adaptateur réseau ne propose pas la configuration manuelle des ressources, soit il configure les ressources de manière dynamique, soit les ressources sont définies sur une valeur fixe qui ne peut pas être modifiée.
Activation de Modération de l’interruption
Pour contrôler la modération de l'interruption, certains adaptateurs réseau proposent différents niveaux de modération de l'interruption, des paramètres de fusion de tampons différents (parfois séparément pour les tampons d'envoi et de réception), ou les deux.
Vous devez envisager la modération des interruptions pour les charges de travail liées au processeur. Lors de l’utilisation de la modération de l'interruption, réfléchissez au compromis entre les ressources processeur économisées côté hôte et la latence, versus les ressources processeur supplémentaires économisées côté hôte en raison des interruptions plus nombreuses et de la latence plus faible. Si l’adaptateur réseau n’effectue pas de modération des interruptions, mais qu’il expose la coalescence des tampons, vous pouvez améliorer les performances en augmentant le nombre de tampons fusionnés pour permettre un plus grand nombre de tampons par envoi ou réception.
Réglage des performances pour le traitement à latence faible des paquets
De nombreuses cartes réseaux proposent des options permettant d'optimiser la latence induite par le système d'exploitation. La latence est la durée qui sépare le traitement d'un paquet entrant par le pilote réseau et le renvoi du paquet par ce pilote. Cette durée est généralement mesurée en microsecondes. À titre de comparaison, la durée de transmission de paquets sur de longues distances est généralement mesurée en millisecondes (un ordre de magnitude plus grand). Ce réglage ne réduira pas la durée de transit d'un paquet.
Voici quelques suggestions de réglage des performances pour les réseaux sensibles à la microseconde.
Définissez le BIOS de l'ordinateur sur Performances élevées et désactivez les états C. Notez toutefois que cela dépend du système et du BIOS et que les performances de certains systèmes seront meilleures si le système d'exploitation contrôle la gestion de l'alimentation. Vous pouvez vérifier et ajuster les paramètres de gestion de l'alimentation dans Paramètres ou à l'aide de la commande powercfg. Pour plus d’informations, voir Options de ligne de commande Powercfg.
Définissez le profil de gestion de l'alimentation du système d'exploitation sur Système hautes performances.
Remarque
Ce paramètre ne fonctionnera pas correctement si le BIOS système a été défini pour désactiver le contrôle de la gestion de l'alimentation par le système d'exploitation.
Activez les déchargements statiques. Par exemple, activez les paramètres Sommes de contrôle UDP, Sommes de contrôle TCP et Envoyer un déchargement volumineux (LSO).
Si le trafic est multi-diffusé, par exemple lors de la réception d’un trafic multidiffusion à volume élevé, activez RSS.
Désactivez le paramètre Modération de l'interruption pour les pilotes de carte réseau qui requièrent la latence la plus faible possible. Rappelez-vous que cette configuration peut utiliser plus de temps processeur et qu'il représente un compromis.
Gérez les interruptions de carte réseau et les appels de procédure différés (DPC) sur un processeur cœur qui partage le cache d'UC avec le cœur qui est utilisé par le programme (thread utilisateur) qui traite le paquet. Le réglage de l'affinité de l'UC peut être utilisé pour diriger un processus vers certains processeurs logiques, conjointement avec la configuration RSS. L'utilisation du même cœur pour le thread d'interruption, le thread DPC et le thread de mode utilisateur réduit les performances à mesure que la charge augmente du fait de la compétition entre ISR, DPC et le thread pour utiliser le cœur.
Interruptions d'administration système
De nombreux systèmes matériels utilisent Interruptions d’administration système (SMI) pour différentes fonctions de maintenance, notamment le signalement des erreurs mémoire ECC (Error Correction Code), la maintenance de la compatibilité USB héritée, le contrôle du ventilateur et la gestion des paramètres de l’alimentation contrôlée par le BIOS.
L’interface SMI est l’interruption de priorité la plus élevée sur le système et place le processeur en mode de gestion. Ce mode préempte toute autre activité alors que SMI exécute une routine de service d’interruption, généralement contenue dans le BIOS.
Malheureusement, ce comportement peut conduire à des pointes de latence de 100 microsecondes ou davantage.
Si vous avez besoin d'une latence très faible, demandez à votre fournisseur de matériel une version du BIOS qui réduit au maximum les SMI. Ces versions du BIOS sont fréquemment appelées « BIOS à faible latence » ou « BIOS libre SMI ». Dans certains cas, il n’est pas possible pour une plateforme matérielle d’éliminer complètement l’activité SMI, car elle est utilisée pour contrôler les fonctions essentielles (par exemple, les ventilateurs de refroidissement).
Notes
Le système d'exploitation ne peut pas contrôler les SMI car le processeur logique s'exécute dans un mode de maintenance spécial qui empêche l'intervention du système d'exploitation.
Réglage des performances de TCP
Vous pouvez utiliser les éléments suivants pour optimiser les performances TCP.
Réglage automatique de la fenêtre de réception TCP
Dans Windows Vista, Windows Server 2008 et les versions ultérieures de Windows, la pile réseau Windows utilise une fonctionnalité nommée Réglage automatique de la fenêtre de réception TCP pour négocier la taille de la fenêtre de réception TCP. Cette fonctionnalité peut négocier une taille de fenêtre de réception définie pour chaque communication TCP pendant l’établissement de liaison TCP.
Dans les versions antérieures de Windows, la pile réseau Windows utilisait une fenêtre de réception de taille fixe (65 535 octets) qui limitait le débit potentiel global pour les connexions. Le débit total réalisable des connexions TCP peut limiter les scénarios d’utilisation du réseau. Le réglage automatique de la fenêtre de réception TCP permet à ces scénarios d’utiliser entièrement le réseau.
Pour une fenêtre de réception TCP qui a une taille particulière, vous pouvez utiliser l’équation suivante pour calculer le débit total d’une seule connexion.
Débit total réalisable en octets = Taille de la fenêtre de réception TCP en octets * (1 / latence de connexion en secondes)
Par exemple, pour une connexion dont la latence est de 10 ms, le débit total réalisable n’est que de 51 Mbits/s. Cette valeur est raisonnable pour une infrastructure réseau d’entreprise volumineuse. Toutefois, en utilisant le réglage automatique pour ajuster la fenêtre de réception, la connexion peut atteindre le taux de ligne complet d’une connexion de 1 Gbits/s.
Certaines applications définissent la taille de la fenêtre de réception TCP. Si l’application ne définit pas la taille de la fenêtre de réception, la vitesse de liaison détermine la taille comme suit :
- Moins de 1 mégabit par seconde (Mbits/s) : 8 kilo-octets (Ko)
- 1 Mbits/s à 100 Mbits/s : 17 Ko
- 100 Mbits/s à 10 gigabits par seconde (Gbits/s) : 64 Ko
- 10 Gbits/s ou plus : 128 Ko
Par exemple, sur un ordinateur sur lequel une carte réseau de 1 Gbit/s est installée, la taille de la fenêtre doit être de 64 Ko.
Cette fonctionnalité utilise également pleinement d’autres fonctionnalités pour améliorer les performances réseau. Ces fonctionnalités incluent le reste des options TCP définies dans RFC 1323. À l’aide de ces fonctionnalités, les ordinateurs Windows peuvent négocier des tailles de fenêtre de réception TCP plus petites, mais mises à l’échelle à une valeur définie, en fonction de la configuration. Ce comportement est plus facile à gérer pour les appareils réseau.
Remarque
Vous pouvez rencontrer un problème dans lequel l’appareil réseau n’est pas conforme à l’option de mise à l’échelle de la fenêtre TCP, comme défini dans RFC 1323 et, par conséquent, ne prend pas en charge le facteur de mise à l’échelle. Dans ce cas, reportez-vous à l’article 934430 de la base de connaissances, la connectivité réseau échoue lorsque vous essayez d’utiliser Windows Vista derrière un appareil de pare-feu ou contactez l’équipe de support technique de votre fournisseur de périphériques réseau.
Vérifier et configurer le niveau de mise en forme automatique de la fenêtre de réception TCP
Vous pouvez utiliser des commandes netsh ou des applets de commande Windows PowerShell pour passer en revue ou modifier le niveau de mise en forme automatique de la fenêtre de réception TCP.
Notes
Contrairement aux versions de Windows antérieures à Windows 10 ou Windows Server 2019, vous ne pouvez plus utiliser le Registre pour configurer la taille de la fenêtre de réception TCP. Pour plus d’informations sur les paramètres déconseillés, consultez Paramètres TCP dépréciés.
Notes
Pour plus d’informations sur les niveaux de réglage automatique disponibles, consultez Niveaux de réglage automatique.
Pour utiliser netsh pour passer en revue ou modifier le niveau de réglage automatique
Pour passer en revue les paramètres actuels, ouvrez une fenêtre d’invite de commandes et exécutez la commande suivante :
netsh interface tcp show global
La sortie de cette commande doit ressembler à ce qui suit :
Querying active state...
TCP Global Parameters
-----
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
Fast Open : enabled
Fast Open Fallback : enabled
Pacing Profile : off
Pour modifier le paramètre, exécutez la commande suivante à l’invite de commandes :
netsh interface tcp set global autotuninglevel=<Value>
Notes
Dans la commande précédente, <Valeur> représente la nouvelle valeur pour le niveau de réglage automatique.
Pour plus d’informations sur cette commande, consultez Commandes Netsh pour le protocole de contrôle de transmission d’interface.
Pour utiliser PowerShell pour passer en revue ou modifier le niveau de mise en forme automatique
Pour passer en revue les paramètres actuels, ouvrez une fenêtre PowerShell et exécutez l’applet de commande suivante.
Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal
La sortie de cette applet de commande doit ressembler à ce qui suit.
SettingName AutoTuningLevelLocal
----------- --------------------
Automatic
InternetCustom Normal
DatacenterCustom Normal
Compat Normal
Datacenter Normal
Internet Normal
Pour modifier le paramètre, exécutez l’applet de commande suivante à l’invite de commandes PowerShell.
Set-NetTCPSetting -AutoTuningLevelLocal <Value>
Remarque
Dans la commande précédente, <Valeur> représente la nouvelle valeur pour le niveau de réglage automatique.
Pour plus d’informations sur ces applets de commande, consultez les articles suivants :
Niveaux de réglage automatique
Vous pouvez définir la mise en forme automatique de fenêtre sur l’un des cinq niveaux. Le niveau par défaut est Normal. Le tableau ci-dessous décrit les niveaux.
| Level | Valeur hexadécimale | Commentaires |
|---|---|---|
| Normale (par défaut) | 0x8 (facteur d’échelle 8) | Définissez la fenêtre de réception TCP pour qu’elle augmente pour prendre en charge presque tous les scénarios. |
| Désactivé | Aucun facteur d’échelle disponible | Définissez la fenêtre de réception TCP à sa valeur par défaut. |
| Limitées | 0x4 (facteur d’échelle 4) | Définissez la fenêtre de réception TCP pour qu’elle augmente au-delà de sa valeur par défaut, mais limitez cette croissance dans certains scénarios. |
| Très restreinte | 0x2 (facteur d’échelle 2) | Définissez la fenêtre de réception TCP pour qu’elle augmente au-delà de sa valeur par défaut, mais faites-le de manière très prudente. |
| Expérimental | 0xE (facteur d’échelle 14) | Définissez la fenêtre de réception TCP pour augmenter pour répondre aux scénarios extrêmes. |
Si vous utilisez une application pour capturer des paquets réseau, l’application doit signaler des données qui ressemblent à ce qui suit pour différents paramètres de niveau de réglage automatique des fenêtres.
Niveau de réglage automatique : Normal (état par défaut)
Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2667, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60975, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240 SrcPort: 60975 DstPort: Microsoft-DS(445) SequenceNumber: 4075590425 (0xF2EC9319) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x8 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 8 -----------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:Niveau de réglage automatique : Désactivé
Frame: Number = 353, Captured Frame Length = 62, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2576, Total IP Length = 48 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60956, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240 SrcPort: 60956 DstPort: Microsoft-DS(445) SequenceNumber: 2315885330 (0x8A099B12) AcknowledgementNumber: 0 (0x0) + DataOffset: 112 (0x70) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( ) = 64240 ----------------------------------------> TCP Receive Window set as 64K as per NIC Link bitrate. Note there is no Scale Factor defined. In this case, Scale factor is not being sent as a TCP Option, so it will not be used by Windows. Checksum: 0x817E, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + NoOption: + SACKPermitted:Niveau de réglage automatique : Restreint
Frame: Number = 3, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2319, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60890, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1966088568, Ack=0, Win=64240 ( Negotiating scale factor 0x4 ) = 64240 SrcPort: 60890 DstPort: Microsoft-DS(445) SequenceNumber: 1966088568 (0x75302178) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x4 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 4 -------------------------------> Scale factor, defined by AutoTuningLevel. + NoOption: + NoOption: + SACKPermitted:Niveau de réglage automatique : Très restreint
Frame: Number = 115, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2388, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60903, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1463725706, Ack=0, Win=64240 ( Negotiating scale factor 0x2 ) = 64240 SrcPort: 60903 DstPort: Microsoft-DS(445) SequenceNumber: 1463725706 (0x573EAE8A) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x2 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 2 ------------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:Niveau de réglage automatique : Expérimental
Frame: Number = 238, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2490, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60933, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2095111365, Ack=0, Win=64240 ( Negotiating scale factor 0xe ) = 64240 SrcPort: 60933 DstPort: Microsoft-DS(445) SequenceNumber: 2095111365 (0x7CE0DCC5) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0xe Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 14 -----------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:
Paramètres TCP dépréciés
Les paramètres de registre suivants de Windows Server 2003 ne sont plus pris en charge et sont ignorés dans les versions ultérieures.
- TcpWindowSize
- NumTcbTablePartitions
- MaxHashTableSize
Tous ces paramètres se trouvaient dans la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Plateforme de filtrage Windows
Windows Vista et Windows Server 2008 ont introduit la plateforme de filtrage Windows (PAM). Le WPF fournit des API aux éditeurs de logiciels indépendants (ISV) non-Microsoft pour créer des filtres de traitement de paquets. Les logiciels pare-feu et antivirus en sont des exemples.
Remarque
Un filtre WFP mal écrit peut réduire significativement les performances de mise en réseau d'un serveur. Pour plus d’informations, consultez Portage de paquets - Transférer les pilotes et applications vers le PAM dans le Centre de développement Windows.
Pour obtenir des liens vers toutes les rubriques de ce guide, consultez Réglage des performances du sous-système réseau.