Compartir a través de

Ajuste del rendimiento del adaptador de red en Windows Server

En este artículo se describe cómo optimizar el rendimiento del adaptador de red en entornos de Windows Server. El ajuste del rendimiento del adaptador de red puede mejorar significativamente el rendimiento, reducir la latencia y maximizar el uso de recursos para las cargas de trabajo del servidor.

La configuración de ajuste correcta de un adaptador de red depende de las siguientes variables:

  • El adaptador de red y su conjunto de características
  • El tipo de carga de trabajo que realiza el servidor
  • Los recursos de hardware y software del servidor
  • Los objetivos de rendimiento para el servidor

La configuración de optimización óptima depende de la configuración de hardware, los requisitos de carga de trabajo y los objetivos de rendimiento específicos. Antes de implementar los cambios, evalúe el rendimiento de la red actual e identifique las áreas para mejorar. Algunas características y configuraciones pueden variar entre versiones.

En las siguientes secciones se describen algunas de las opciones de ajuste del rendimiento.

Características de descarga

La descarga de red ofrece tareas de procesamiento de transferencia de la CPU al hardware del adaptador de red, lo que reduce la sobrecarga del sistema y mejora el rendimiento general de la red. Entre las características comunes de descarga se incluyen la descarga de suma de comprobación TCP, la descarga de envío grande (LSO) y el escalado lateral de recepción (RSS).

Activar las características de descarga del adaptador de red suele ser beneficioso. Sin embargo, puede que el adaptador de red no tenga suficiente capacidad para administrar las funcionalidades de descarga con un rendimiento alto. Por ejemplo, considere un adaptador de red con recursos de hardware limitados. En ese caso, habilitar las características de descarga de segmentación podría reducir el rendimiento máximo sostenible del adaptador. No obstante, si ese rendimiento reducido es aceptable, debe habilitar las características de descarga de segmentación.

Algunos adaptadores de red necesitan que las características de descarga se habiliten de forma independiente para las rutas de envío y recepción.

Important

No use las características de descarga IPsec Task Offload o TCP Chimney Offload. Estas tecnologías están en desuso en Windows Server 2016 y podrían afectar negativamente al rendimiento del servidor y las redes. Además, Es posible que Microsoft no admita estas tecnologías en el futuro.

Escalado en el lado de recepción (RSS) para servidores web

RSS puede mejorar la escalabilidad y el rendimiento web cuando hay menos adaptadores de red que procesadores lógicos en el servidor. Cuando todo el tráfico de la red pasa por adaptadores de red compatibles con RSS, el servidor puede procesar las solicitudes web que llegan de diferentes conexiones de forma simultánea en diferentes CPU.

Important

Evite usar adaptadores de red compatibles y no compatibles con RSS en el mismo servidor. Debido a la lógica de la distribución de la carga y del protocolo de transferencia de hipertexto (HTTP), el rendimiento se puede ver gravemente deteriorado si un adaptador de red no compatible con RSS acepta tráfico web en un servidor que tiene uno o varios adaptadores de red compatibles con RSS. En esta circunstancia, debe usar adaptadores de red compatibles con RSS o deshabilitar RSS en la pestaña Propiedades avanzadas del adaptador de red.

Para determinar si un adaptador de red es compatible con RSS, puede ver la información RSS en la pestaña Propiedades avanzadas del adaptador de red.

Perfiles RSS y colas RSS

El perfil predefinido RSS predeterminado es NUMAStatic. Antes de comenzar a usar perfiles de RSS, puede revisar los perfiles disponibles para saber cuándo son beneficiosos y cómo se aplican a su entorno y hardware de red.

Por ejemplo, abra el Administrador de tareas y revise los procesadores lógicos en el servidor. Si parecen estar infrautilizados para el tráfico de recepción, puede intentar aumentar el número de colas RSS del valor predeterminado de dos al máximo que admite el adaptador de red. Quizás el adaptador de red tenga opciones para cambiar el número de colas RSS como parte del controlador.

Recursos de adaptadores de red

Para los adaptadores de red que le permiten configurar los recursos manualmente, por ejemplo, los búferes de envío y recepción, debe aumentar los recursos asignados.

Algunos adaptadores de red establecen un valor bajo para los búferes de recepción para conservar la memoria asignada del host. El valor bajo produce la pérdida de paquetes y un menor rendimiento. Por lo tanto, en escenarios con un alto volumen de recepción, te recomendamos que aumentes el valor del búfer de recepción al máximo.

Si un adaptador de red no expone la configuración de recursos manual, configura los recursos dinámicamente o están establecidos en un valor fijo que no se puede cambiar.

Moderación de interrupciones

Para controlar la moderación de interrupciones, algunos adaptadores de red ofrecen diferentes niveles de moderación de interrupciones, parámetros de fusión de distintos búferes (algunas veces por separado para los búferes de envío y recepción) o ambos.

Debe considerar la moderación de interrupciones para cargas de trabajo enlazadas a CPU. Cuando use la moderación de interrupciones, tenga en cuenta el equilibrio entre latencia y ahorro de CPU host frente al mayor ahorro de CPU host debido a un mayor número de interrupciones y una menor latencia. Si el adaptador de red no realiza moderación de interrupciones, pero expone fusión de búferes, puede mejorar el rendimiento aumentando el número de búferes fusionados para permitir más búferes por envío o recepción.

Procesamiento de paquetes de baja latencia

Muchos adaptadores de red ofrecen opciones para optimizar la latencia inducida por el sistema operativo. La latencia es el tiempo que transcurre desde que el controlador de red procesa un paquete de entrada hasta que lo envía de vuelta. Este tiempo suele medirse en microsegundos. En comparación, el tiempo de transmisión en transmisiones de paquetes en grandes distancias suele medirse en milisegundos (un orden de magnitud mayor). Este ajuste no reducirá el tiempo que un paquete está en tránsito.

La lista siguiente muestra algunas sugerencias de ajuste para redes con una sensibilidad de microsegundos:

  • Si el BIOS lo admite, establezca el BIOS del equipo en Alto rendimiento, con C-states deshabilitado. Algunos sistemas proporcionan un mayor rendimiento si el sistema operativo controla la administración de energía. Puede comprobar y ajustar la configuración de administración de energía desde la configuración de energía o mediante el comando powercfg. Para más información, consulte Opciones de la línea de comandos Powercfg.

  • Establece el perfil de administración de energía del sistema operativo en Sistema de alto rendimiento. Esta configuración no funciona correctamente si el BIOS del sistema está establecido para deshabilitar el control del sistema operativo de la administración de energía.

  • Habilite las descargas estáticas. Por ejemplo, habilite UDP Checksums, TCP Checksums y Send Large Offload (LSO).

  • Si el tráfico se transmite en varias secuencias, como al recibir tráfico de multidifusión de gran volumen, habilite RSS.

  • Deshabilite la opción Moderación de interrupciones para los controladores de tarjeta de red que requieren la latencia más baja posible. Recuerde que esta configuración puede usar más tiempo de CPU y esto puede suponer un inconveniente.

  • Administra las interrupciones y DPC de los adaptadores de red en un procesador de núcleo que comparta la memoria caché de la CPU con el núcleo usado por el programa (subproceso de usuario) que está administrando el paquete. El ajuste de afinidad de CPU se puede usar para dirigir un proceso a determinados procesadores lógicos con configuración RSS. Cuando se usa el mismo núcleo para la interrupción, el DPC y el subproceso del modo de usuario, el rendimiento es menor porque la carga aumenta debido a que el ISR, DPC y el subproceso luchan por usar el núcleo.

Interrupciones de administración del sistema

Muchos sistemas de hardware usan interrupciones de administración del sistema (SMI) para diversas funciones de mantenimiento, como la notificación de errores de memoria de código de corrección de errores (ECC), compatibilidad con USB heredados, control de ventiladores y administración de la energía controlada por BIOS.

Las SMI constituyen la interrupción de prioridad más alta en el sistema y coloca la CPU en un modo de administración. Este modo impide cualquier otra actividad mientras SMI ejecuta una rutina de servicio de interrupción, normalmente contenida en BIOS. Lamentablemente, este comportamiento puede producir picos de latencia de 100 microsegundos o más.

Si necesitas lograr la menor latencia, debes solicitar a tu proveedor de hardware una versión del BIOS que reduzca los SMI al mínimo posible. Estas versiones de la BIOS suelen denominarse BIOS de baja latencia o SMI sin BIOS. En algunos casos, en una plataforma de hardware no se puede eliminar la actividad de SMI por completo porque se usa para controlar funciones esenciales, como los ventiladores de refrigeración.

El sistema operativo puede no controlar las SMI porque el procesador lógico se está ejecutando en un modo de mantenimiento especial que impide la intervención del sistema operativo.

Optimización automática de la ventana de recepción de TCP

La pila de red de Windows usa una característica denominada nivel de ajuste automático de ventana de recepción TCP para negociar el tamaño de la ventana de recepción TCP. Esta característica puede negociar un tamaño de ventana de recepción definido para cada comunicación TCP durante el protocolo de enlace TCP y puede mejorar el rendimiento de las conexiones TCP.

Anteriormente, la pila de red de Windows usaba una ventana de recepción de tamaño fijo de 65 535 bytes que limitaban el rendimiento potencial general de las conexiones. El rendimiento total factible de las conexiones TCP podría limitar los escenarios de uso de red. El ajuste automático de la ventana de recepción TCP permite que estos escenarios usen completamente la red.

Para una ventana de recepción TCP con un tamaño determinado, puede usar la siguiente ecuación para calcular el rendimiento total de una sola conexión:

Rendimiento total factible en bytes = Tamaño de la ventana de recepción de TCP en bytes * (1 / latencia de conexión en segundos)

Por ejemplo, para una conexión de 1Gbps que tiene una latencia de 10 ms, el rendimiento total factible es de solo 51 Mbps. Este valor es razonable para una gran infraestructura de red corporativa. Sin embargo, mediante el ajuste automático para ajustar la ventana de recepción, la conexión puede lograr la velocidad de línea completa de 1 Gbps.

Algunas aplicaciones definen el tamaño de la ventana de recepción de TCP. Si la aplicación no define el tamaño de la ventana de recepción, la velocidad del vínculo determina el tamaño como se indica a continuación:

Velocidad de vínculo Tamaño de ventana de recepción
Menos de 1 Mbps 8 KB
De 1 Mbps a 100 Mbps 17 KB
De 100 Mbps a 10 Gbps 64 KB
10 Gbps o más rápida 128 KB

Por ejemplo, en un equipo que tiene instalado un adaptador de red de 1 Gbps, el tamaño de la ventana debe ser de 64 KB.

Esta característica también hace uso completo de otras características para mejorar el rendimiento de la red. Estas características incluyen el resto de las opciones TCP definidas en RFC 1323. Los equipos basados en Windows pueden usar estas características para negociar los tamaños de ventana de recepción TCP que son más pequeños, pero que se escalan a un valor definido, en función de la configuración. Este comportamiento facilita el control de los tamaños de los dispositivos de red.

Note

Es posible que experimente un problema en el que el dispositivo de red no es compatible con la opción de escalado de ventanas TCP, tal como se define en RFC 1323 y, por lo tanto, no admite el factor de escala. En tales casos, póngase en contacto con el proveedor del dispositivo de red.

Niveles de ajuste automático

Puede establecer la optimización automática de la ventana de recepción de TCP en cualquiera de estos cinco niveles. El nivel predeterminado es Normal. Los niveles se describen en la siguiente tabla.

Level Valor hexadecimal Comments
Normal (valor predeterminado) 0x8 (factor de escalado de 8) Establezca la ventana de recepción de TCP para que crezca y pueda dar cabida a casi todos los escenarios.
Disabled No hay ningún factor de escalado disponible Establezca la ventana de recepción de TCP en su valor predeterminado.
Restricted 0x4 (factor de escalado de 4) Establezca la ventana de recepción de TCP para que crezca más allá de su valor predeterminado, pero limite este crecimiento en algunos escenarios.
Altamente restringido 0x2 (factor de escalado de 2) Establezca la ventana de recepción de TCP para que crezca más allá de su valor predeterminado, pero hágalo de forma muy conservadora.
Experimental 0xE (factor de escalado de 14) Establezca la ventana de recepción de TCP para que crezca y pueda dar cabida a escenarios extremos.

Si usa una aplicación para capturar paquetes de red, la aplicación debe notificar datos similares a los ejemplos siguientes para la configuración de nivel de ajuste automático de ventanas diferente.

Nivel de optimización automática: Normal (estado predeterminado)

En este ejemplo se muestra la salida de una herramienta de captura de paquetes cuando el nivel de ajuste automático de la ventana de recepción TCP está establecido en Normal. El factor de escala es 8.

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:

Nivel de optimización automática: Deshabilitado

En este ejemplo se muestra la salida de una herramienta de captura de paquetes cuando el nivel de ajuste automático de la ventana de recepción TCP está establecido en Deshabilitado. No se usa el factor de escala.

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:

Nivel de optimización automática: Restringido

En este ejemplo se muestra la salida de una herramienta de captura de paquetes cuando el nivel de ajuste automático de la ventana de recepción TCP está establecido en Restringido. El factor de escala es 4.

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:

Nivel de optimización automática: Muy restringido

En este ejemplo se muestra la salida de una herramienta de captura de paquetes cuando el nivel de ajuste automático de la ventana de recepción TCP está establecido en Altamente restringido. El factor de escala es 2.

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:

Nivel de optimización automática: Experimental

En este ejemplo se muestra la salida de una herramienta de captura de paquetes cuando el nivel de ajuste automático de la ventana de recepción TCP está establecido en Experimental. El factor de escala es 14.

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:

Revisión y configuración del nivel de optimización automática de la ventana de recepción de TCP

Puede usar cmdlets de Windows PowerShell o el comando netsh de Windows para revisar o cambiar el nivel de ajuste automático de la ventana de recepción TCP.

Note

A partir de Windows Server 2019, ya no puede usar el Registro para configurar el tamaño de la ventana de recepción TCP. Para más información sobre los valores en desuso, consulte Parámetros de TCP en desuso.

Puede usar el cmdlet Get-NetTCPSetting para revisar o modificar el nivel de ajuste automático. Para revisar y cambiar la configuración actual:

  1. Abra PowerShell como administrador y ejecute el siguiente cmdlet:

    Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

    La salida es similar a la del ejemplo siguiente:

    SettingName          AutoTuningLevelLocal
-----------          --------------------
Automatic
InternetCustom       Normal
DatacenterCustom     Normal
Compat               Normal
Datacenter           Normal
Internet             Normal

  2. Para cambiar esta configuración, ejecute el siguiente comando. Asegúrese de establecer <value> en el nivel de ajuste automático deseado. Para obtener más información, vea Set-NetTCPSetting.

    Set-NetTCPSetting -AutoTuningLevelLocal <value>

Plataforma de filtrado de Windows

La Plataforma de filtrado de Windows (PMA), introducida en Windows Server 2008, proporciona API a proveedores de software independientes de Microsoft (ISV) para crear filtros de procesamiento de paquetes. EL PMA permite que el software de terceros inspeccione, modifique o filtre el tráfico de red en varias capas de la pila de red. Aunque esta funcionalidad es esencial para las aplicaciones de seguridad, puede introducir una sobrecarga de rendimiento si no se implementa correctamente. Algunos ejemplos son firewall y software antivirus.

Un filtro de WFP escrito de forma deficiente puede reducir significativamente el rendimiento de red de un servidor. Para más información, consulte Traslado de controladores y aplicaciones de procesamiento de paquetes a WFP en el Centro de desarrollo de Windows.

Parámetros de TCP en desuso

Los siguientes valores de registro de Windows Server 2003 ya no son compatibles y se omiten en versiones posteriores.

  • TcpWindowSize
  • NumTcbTablePartitions
  • MaxHashTableSize

Todos estos valores se encontraron en la siguiente subclave del registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

  • Last updated on