Réglage des performances des cartes réseau

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.