Ajustar el rendimiento de los adaptadores de red
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016; Azure Stack HCI, versiones 21H2 y 20H2
Use la información de este tema para optimizar los adaptadores de red de rendimiento de los equipos que ejecutan Windows Server 2016 y versiones posteriores. Si los adaptadores de red proporcionan opciones de optimización, puede usar estas opciones para optimizar el rendimiento de la red y el uso de recursos.
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
En las siguientes secciones se describen algunas de las opciones de ajuste del rendimiento.
Habilitar las características de descarga
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.
Importante
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.
Por ejemplo, considere la posibilidad de usar un adaptador de red que tenga 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 continuar y habilitar las características de descarga de segmentación.
Nota
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.
Habilitar el ajuste de escala 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.
Importante
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 este caso, debes usar adaptadores de red compatibles con RSS o deshabilitar RSS en la pestaña Propiedades avanzadas de las propiedades del adaptador de red.
Para determinar si un adaptador de red es compatible con RSS, puedes ver la información de RSS en la pestaña Propiedades avanzadas de las propiedades del adaptador de red.
Perfiles RSS y colas RSS
El perfil de RSS predefinido predeterminado es NUMAStatic, que difiere del valor predeterminado que usaban las versiones anteriores de Windows. Antes de empezar a usar los perfiles de RSS, revise los perfiles disponibles para saber cuándo son beneficiosos y cómo se aplican a su entorno y hardware de red.
Por ejemplo, si abre el Administrador de tareas, revisa los procesadores lógicos del servidor y parecen estar infrautilizados para la recepción de tráfico, puede intentar aumentar el número de colas RSS de las dos predeterminadas al máximo que admita su adaptador de red. Quizás el adaptador de red tenga opciones para cambiar el número de colas RSS como parte del controlador.
Aumento de los 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.
Nota
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.
Habilitar la 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, aumentar el número de búferes fusionados permite más búferes por envío o recepción, lo que mejora el rendimiento.
Optimización del rendimiento para el 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.
Las siguientes son algunas sugerencias de ajuste para redes con una sensibilidad de microsegundos.
Establece el BIOS del equipo en Alto rendimiento, con C-states deshabilitado. Sin embargo, ten en cuenta que esto depende del BIOS y del sistema, y que algunos sistemas proporcionarán un rendimiento mayor si el sistema operativo controla la administración de la energía. Puede consultar y ajustar la configuración de la administración de energía en Configuración 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.
Nota
Esta configuración no funcionará correctamente si el BIOS del sistema se ha establecido para deshabilitar el control de la administración de energía en el sistema operativo.
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.
Deshabilita la opción Moderación de interrupciones para los controladores de tarjetas de red que requieran la menor latencia 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. Para ello, se puede usar el ajuste de la afinidad de la CPU para dirigir un proceso a determinados procesadores lógicos junto con la configuración de 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 BIOS se conocen con frecuencia como "BIOS de baja latencia" o "BIOS sin SMI". 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 (por ejemplo, los ventiladores de refrigeración).
Nota
El sistema operativo no puede 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 del rendimiento de TCP
Puede usar los siguientes elementos para optimizar el rendimiento de TCP.
Optimización automática de la ventana de recepción de TCP
En Windows Vista, Windows Server 2008 y versiones posteriores de Windows, la pila de red de Windows usa una característica denominada nivel de optimización automática de la ventana de recepción de TCP para negociar el tamaño de la ventana de recepción de 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.
En versiones anteriores de Windows, la pila de red de Windows usaba una ventana de recepción de tamaño fijo (65 535 bytes) que limitaba el rendimiento global de las conexiones. El rendimiento total factible de las conexiones TCP podría limitar los escenarios de uso de red. La optimización automática de ventanas 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 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, si ajusta la ventana de recepción mediante la optimización automática, la conexión puede lograr la velocidad de línea completa de una conexión 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 de la siguiente manera:
- Menos de 1 megabit por segundo (Mbps): 8 kilobytes (KB)
- 1 Mbps a 100 Mbps: 17 KB
- 100 Mbps a 10 gigabits por segundo (Gbps): 64 KB
- 10 Gbps o más rápido: 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. Mediante estas características, los equipos basados en Windows pueden negociar tamaños de ventana de recepción de TCP más pequeños, pero que se escalan a un valor definido, en función de la configuración. Este comportamiento es más fácil de controlar para los dispositivos de red.
Nota
Puede experimentar un problema en el que el dispositivo de red no es compatible con la opción de escalado de ventanas de TCP, tal como se define en RFC 1323 y, por lo tanto, no admite el factor de escalado. En tales casos, consulte este KB 934430, Error en la conectividad de red cuando intenta usar Windows Vista detrás de un dispositivo de firewall o póngase en contacto con el equipo de soporte técnico del proveedor de dispositivos de red.
Revisión y configuración del nivel de optimización automática de la ventana de recepción de TCP
Puede usar comandos netsh o cmdlets de Windows PowerShell para revisar o modificar el nivel de optimización automática de la ventana de recepción de TCP.
Nota
A diferencia de las versiones de Windows anteriores a Windows 10 o Windows Server 2019, ya no puede usar el registro para configurar el tamaño de la ventana de recepción de TCP. Para más información sobre los valores en desuso, consulte Parámetros de TCP en desuso.
Nota
Para obtener información detallada sobre los niveles de optimización automática disponibles, consulte Niveles de optimización automática.
Para usar netsh para revisar o modificar el nivel de optimización automática
Para revisar la configuración actual, abra una ventana del símbolo del sistema y ejecute el siguiente comando:
netsh interface tcp show global
La salida de este comando debe ser similar a la siguiente:
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
Para modificar la configuración, ejecute el siguiente comando en el símbolo del sistema:
netsh interface tcp set global autotuninglevel=<Value>
Nota
En el comando anterior, <Value> representa el nuevo valor del nivel de optimización automática.
Para más información sobre este comando, consulte Comandos de Netsh para el Protocolo de control de transmisión de interfaz.
Para usar PowerShell para revisar o modificar el nivel de optimización automática
Para revisar la configuración actual, abra una ventana de PowerShell y ejecute el siguiente cmdlet.
Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal
La salida de este cmdlet debe ser similar a la siguiente.
SettingName AutoTuningLevelLocal
----------- --------------------
Automatic
InternetCustom Normal
DatacenterCustom Normal
Compat Normal
Datacenter Normal
Internet Normal
Para modificar la configuración, ejecute el siguiente cmdlet en el símbolo del sistema de PowerShell.
Set-NetTCPSetting -AutoTuningLevelLocal <Value>
Nota
En el comando anterior, <Value> representa el nuevo valor del nivel de optimización automática.
Para más información sobre estos cmdlets, consulte los siguientes artículos:
Niveles de optimización automática
Puede establecer la optimización automática de la ventana de recepción en cualquiera de estos cinco niveles. El nivel predeterminado es Normal. Los niveles se describen en la siguiente tabla.
| Nivel | Valor hexadecimal | Comentarios |
|---|---|---|
| Normal (opción predeterminada) | 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. |
| Restringidos | 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. |
| Muy 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. |
| Habilitación de características | 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 siguientes para los diferentes valores de nivel de optimización de la ventana.
Nivel de optimización automática: Normal (estado predeterminado)
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
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
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
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
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:
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
Plataforma de filtrado de Windows
Windows Vista y Windows Server 2008 introdujeron la Plataforma de filtrado de Windows (WFP). Esta plataforma proporciona API a proveedores de software independientes (ISV) ajenos a Microsoft para crear filtros de procesamiento de paquetes. Algunos ejemplos son firewall y software antivirus.
Nota
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.
Para obtener vínculos a todos los temas de esta guía, consulte Optimización del rendimiento del subsistema de red.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de