Ajuste de desempenho do adaptador de rede no Windows Server

Este artigo descreve como otimizar o desempenho do adaptador de rede em ambientes Windows Server. O ajuste de desempenho do adaptador de rede pode melhorar significativamente a taxa de transferência, reduzir a latência e maximizar a utilização de recursos para as cargas de trabalho do servidor.

As configurações de ajuste corretas para seus adaptadores de rede dependem das seguintes variáveis:

• O adaptador de rede e seu conjunto de recursos
• O tipo de carga de trabalho que o servidor executa
• Os recursos de hardware e software do servidor
• Suas metas de desempenho para o servidor

As configurações ideais de ajuste dependem da configuração específica de hardware, dos requisitos de carga de trabalho e dos objetivos de desempenho. Antes de implementar alterações, avalie o desempenho atual da rede e identifique áreas para melhorias. Alguns recursos e configurações podem variar entre as versões.

As seções a seguir descrevem algumas de suas opções de ajuste de desempenho.

Recursos de descarregamento

Os recursos de descarregamento de rede transferem tarefas de processamento da CPU para o hardware do adaptador de rede, reduzindo a sobrecarga do sistema e melhorando o desempenho geral da rede. Os recursos comuns de descarregamento incluem descarregamento da soma de verificação TCP, Large Send Offload (LSO) e Receive Side Scaling (RSS).

Habilitar os recursos de descarregamento do adaptador de rede geralmente é benéfico. No entanto, o adaptador de rede pode não ser suficientemente poderoso para lidar com as capacidades de descarregamento com uma alta taxa de transferência. Por exemplo, considere um adaptador de rede com recursos de hardware limitados. Nesse caso, ativar funcionalidades de descarregamento de segmentação pode reduzir a taxa de transferência máxima sustentável do adaptador. No entanto, se a taxa de transferência reduzida for aceitável, deverá ativar as funcionalidades de offload de segmentação.

Alguns adaptadores de rede exigem que se habilitem os recursos de descarregamento de forma independente para os caminhos de envio e recebimento.

Receive-side scaling (RSS) para servidores Web

O RSS pode melhorar a escalabilidade e o desempenho da Web quando há menos adaptadores de rede do que processadores lógicos no servidor. Quando todo o tráfego da Web está passando pelos adaptadores de rede compatíveis com RSS, o servidor pode processar solicitações da Web de entrada de diferentes conexões simultaneamente em diferentes CPUs.

Perfis RSS e filas RSS

O perfil predefinido RSS padrão é NUMAStatic. Antes de começar a usar perfis RSS, revise os perfis disponíveis para entender quando eles são benéficos e como eles se aplicam ao seu ambiente de rede e hardware.

Por exemplo, abra o Gestor de Tarefas e reveja os processadores lógicos no servidor. Se eles parecerem estar subutilizados para o tráfego de recebimento, você pode tentar aumentar o número de filas RSS do padrão de dois para o máximo que seu adaptador de rede suporta. O adaptador de rede pode ter opções para alterar o número de filas RSS como parte do driver.

Recursos do adaptador de rede

Para adaptadores de rede que permitem configurar manualmente recursos como buffers de recebimento e envio, você deve aumentar os recursos alocados.

Alguns adaptadores de rede definem seus buffers de recebimento baixos para conservar a memória alocada do host. O baixo valor resulta em pacotes descartados e desempenho diminuído. Portanto, para cenários de recebimento intensivo, recomendamos que você aumente o valor do buffer de recebimento ao máximo.

Se um adaptador de rede não expõe a configuração manual de recursos, ele configura dinamicamente os recursos ou os recursos são definidos para um valor fixo que não pode ser alterado.

Moderação de Interrupções

Para controlar a moderação de interrupção, alguns adaptadores de rede expõem diferentes níveis de moderação de interrupção, diferentes parâmetros de coalescência de buffer (às vezes separadamente para buffers de envio e recebimento) ou ambos.

Você deve considerar a moderação das interrupções para cargas de trabalho ligadas à CPU. Ao usar a moderação de interrupção, considere a compensação entre a economia e a latência da CPU do host versus a maior economia da CPU do host devido a mais interrupções e menos latência. Se o adaptador de rede não executar a moderação de interrupção, mas oferecer a coalescência de buffers, é possível melhorar o desempenho aumentando o número de buffers coalescidos para permitir mais buffers por envio ou receção.

Processamento de pacotes de baixa latência

Muitos adaptadores de rede fornecem opções para otimizar a latência induzida pelo sistema operacional. Latência é o tempo decorrido entre o driver de rede que processa um pacote de entrada e o driver de rede que envia o pacote de volta. Este tempo é geralmente medido em microssegundos. Para comparação, o tempo de transmissão para transmissões de pacotes em longas distâncias é geralmente medido em milissegundos (uma ordem de grandeza maior). Esse ajuste não reduz o tempo que um pacote passa em trânsito.

A lista a seguir fornece algumas sugestões de ajuste de desempenho para redes sensíveis a microssegundos:

• Se o BIOS suportar, defina o BIOS do computador como Alto Desempenho, com C-states desativado. Alguns sistemas oferecem maior desempenho se o sistema operacional controlar o gerenciamento de energia. Pode verificar e ajustar as suas definições de gestão de energia a partir das definições de energia ou utilizando o powercfg comando. Para obter mais informações, consulte Opções de Command-Line do Powercfg.

• Defina o perfil de gerenciamento de energia do sistema operacional como Sistema de Alto Desempenho. Essa configuração não funcionará corretamente se o BIOS do sistema estiver configurado para desativar o controle do sistema operacional de gerenciamento de energia.

• Habilite descarregamentos estáticos. Por exemplo, habilite as configurações UDP Checksums, TCP Checksums e Send Large Offload (LSO).

• Se o tráfego for multifluxo, como ao receber tráfego multicast de alto volume, ative o RSS.

• Desative a configuração de moderação de interrupção para drivers de placa de rede que exigem a menor latência possível. Lembre-se, essa configuração pode usar mais tempo de CPU e representa uma compensação.

• Gerencie interrupções do adaptador de rede e DPC em um núcleo de processador que partilha o cache da CPU com o núcleo que está sendo usado pelo programa (thread de utilizador) que está manipulando o pacote. O ajuste de afinidade da CPU pode ser usado para direcionar um processo para determinados processadores lógicos com configuração RSS. Usar o mesmo núcleo para a interrupção, o DPC e o thread em modo de utilizador resulta em um desempenho pior à medida que a carga aumenta, porque o ISR, o DPC e o thread disputam o uso do núcleo.

Interrupções no gerenciamento do sistema

Muitos sistemas de hardware usam Interrupções de Gerenciamento do Sistema (SMI) para várias funções de manutenção, como reportar erros de memória com código de correção de erros (ECC), manter a compatibilidade USB legada, controlar o ventilador e gerenciar configurações de energia controladas pelo BIOS.

O SMI é a interrupção de prioridade mais alta no sistema e coloca a CPU em um modo de gerenciamento. Esse modo antecipa todas as outras atividades, enquanto o SMI executa uma rotina de serviço de interrupção, normalmente contida no BIOS. Infelizmente, esse comportamento pode resultar em picos de latência de 100 microssegundos ou mais.

Se você precisar alcançar a menor latência, solicite uma versão do BIOS do seu provedor de hardware que reduza as SMIs ao menor grau possível. Essas versões do BIOS são frequentemente chamadas de BIOS de baixa latência ou BIOS livre de SMI. Em alguns casos, não é possível que uma plataforma de hardware elimine completamente a atividade SMI porque ela é usada para controlar funções essenciais, como ventiladores de resfriamento.

O sistema operacional não pode controlar SMIs porque o processador lógico está sendo executado em um modo de manutenção especial, o que impede a intervenção do sistema operacional.

Ajuste automático da janela de recebimento TCP

A pilha de rede do Windows usa um recurso chamado nível de ajuste automático da janela de receção TCP para determinar o tamanho da janela de receção TCP. Esse recurso pode negociar um tamanho de janela de recebimento definido para cada comunicação TCP durante o Handshake TCP e pode melhorar o desempenho de conexões TCP.

Anteriormente, a pilha de rede do Windows usava uma janela de recebimento de tamanho fixo de 65.535 bytes que limitava a taxa de transferência potencial geral para conexões. A taxa de transferência total alcançável de conexões TCP pode limitar os cenários de uso da rede. O ajuste automático da janela de recebimento TCP permite que esses cenários usem totalmente a rede.

Para uma janela de recebimento TCP que tem um tamanho específico, você pode usar a seguinte equação para calcular a taxa de transferência total de uma única conexão:

Taxa de transferência total alcançável em bytes = Tamanho da janela de receção TCP em bytes * (1 / latência de ligação em segundos)

Por exemplo, para uma conexão de 1 Gbps que tem uma latência de 10 ms, a taxa de transferência total alcançável é de apenas 51 Mbps. Esse valor é razoável para uma grande infraestrutura de rede corporativa. No entanto, usando o ajuste automático para ajustar a janela de recebimento, a conexão pode atingir a taxa de linha completa de 1 Gbps.

Algumas aplicações definem o tamanho da janela de receção TCP. Se o aplicativo não definir o tamanho da janela de recebimento, a velocidade do link determinará o tamanho da seguinte maneira:

Por exemplo, em um computador que tenha um adaptador de rede de 1 Gbps instalado, o tamanho da janela deve ser de 64 KB.

Este recurso também faz pleno uso de outros recursos para melhorar o desempenho da rede. Esses recursos incluem o restante das opções TCP definidas no RFC 1323. Os computadores baseados no Windows podem usar esses recursos para negociar tamanhos de janela de recebimento TCP que são menores, mas são dimensionados em um valor definido, dependendo da configuração. Esse comportamento torna os tamanhos mais fáceis de manipular para dispositivos de rede.

Níveis de ajuste automático

Você pode definir o ajuste automático da janela de recebimento TCP para qualquer um dos cinco níveis. O nível padrão é Normal. A tabela a seguir descreve os níveis.

Se você usar um aplicativo para capturar pacotes de rede, o aplicativo deverá relatar dados semelhantes aos exemplos a seguir para diferentes configurações de nível de ajuste automático de janela.

Nível de ajuste automático: Normal (estado padrão)

Este exemplo mostra a saída de uma ferramenta de captura de pacotes quando o nível de ajuste automático da janela de recebimento TCP está definido como Normal. O fator de escala é 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:

Nível de ajuste automático: desativado

Este exemplo mostra a saída de uma ferramenta de captura de pacotes quando o nível de ajuste automático da janela de recebimento TCP está definido como Disabled. O fator de escala não é usado.

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:

Nível de ajuste automático: Restrito

Este exemplo mostra a saída de uma ferramenta de captura de pacotes quando o nível de ajuste automático da janela de recebimento TCP está definido como Restrito. O fator de escala é 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:

Nível de ajuste automático: altamente restrito

Este exemplo mostra a saída de uma ferramenta de captura de pacotes quando o nível de ajuste automático da janela de recebimento TCP está definido como Altamente restrito. O fator de escala é 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:

Nível de autotuning: Experimental

Este exemplo mostra a saída de uma ferramenta de captura de pacotes quando o nível de ajuste automático da janela de recebimento TCP é definido como Experimental. O fator de escala é 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:

Revise e configure o nível de ajuste automático da janela de recebimento TCP

Você pode usar cmdlets do Windows PowerShell ou o netsh comando do Windows para revisar ou alterar o nível de ajuste automático da janela de recebimento TCP.

Plataforma de Filtragem do Windows

A Plataforma de Filtragem do Windows (WFP), introduzida no Windows Server 2008, fornece APIs a ISVs (fornecedores independentes de software) que não são da Microsoft para criar filtros de processamento de pacotes. O WFP permite que software de terceiros inspecione, modifique ou filtre o tráfego de rede em várias camadas da pilha de rede. Embora essa funcionalidade seja essencial para aplicativos de segurança, ela pode introduzir sobrecarga de desempenho se não for implementada corretamente. Os exemplos incluem firewall e software antivírus.

Um filtro WFP mal escrito pode diminuir significativamente o desempenho de rede de um servidor. Para obter mais informações, consulte Portabilidade de drivers e aplicativos Packet-Processing para o WFP no Centro de Desenvolvimento do Windows.

Parâmetros TCP preteridos

As seguintes configurações do Registro do Windows Server 2003 não são mais suportadas e são ignoradas em versões posteriores.

• TcpWindowSize
• NumTcbTablePartitions
• MaxHashTableSize

Todas essas configurações foram localizadas na seguinte subchave do Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters