Como melhorar a taxa de transferência da Intel X520-DA2 10Gb sem pacotes Jumbo

Question

Veja o que eu fiz até agora:

O uso de mais buffers Rx / Tx aumenta o desempenho dos padrões. Eu configurei as Filas de RSS para 4 em cada adaptador e especifiquei a inicialização da CPU de RSS na segunda porta para algo diferente de 0 (são 16 no PC que eu uso, com 16 núcleos, 32 HTs).

Ao assistir o ProcessExplorer, estou limitado pela capacidade da CPU de lidar com o grande número de interrupções recebidas, mesmo com o RSS ativado. Estou usando o slot PCIe x8 (elétrico) no modo 2.x. Cada um dos dois adaptadores se conecta com um barramento de 5GT / s x8.

A capacidade de resposta do SO não importa, a taxa de transferência de E / S faz. Estou limitado pela incapacidade dos clientes de processar pacotes Jumbo.

Quais configurações devo tentar agora?

Detalhes: Dual Xeon-E5 2665, 32 GB de RAM, oito SSDs em RAID0 (RAMDrive usado para validação de NIC perf), dados de 1 TB para serem movidos via IIS / FTP de 400 clientes, o mais rápido possível.

Em resposta aos comentários:

A taxa de transferência de leitura real é de 650 MB / s em um par agrupado de links de 10 Gb / s na RAM Drive

Antivírus e firewall estão desativados, AFAICT. (Eu tenho bastante bom controle sobre o que está instalado no PC, neste caso. Como posso ter certeza de que nenhum filtro está reduzindo o desempenho? Vou ter que seguir, bom ponto.)

No Process Explorer, vejo períodos de tempo em que a CPU continua (vermelho, hora do kernel), mas a E / S da rede e do disco está parada

Max processadores RSS estão no seu valor padrão, 16

Entradas com sinal de mensagem são suportadas em ambas as instâncias do dispositivo X520-DA2, com MessageNumberLimit configurado para 18. Aqui está o que eu vejo na minha placa de desktop mais simples

    

Answer 1

Um dos problemas com as placas de rede de alto desempenho é que a arquitetura moderna do PC tem um pouco de dificuldade para se manter. Mas, no seu caso, isso não é tanto o problema. Deixe-me explicar.

A CPU precisa trabalhar muito no processamento de pacotes TCP. Isso afeta o rendimento. O que está limitando as coisas no seu caso não é o hardware de rede, mas a capacidade do servidor de saturar os links de rede.

Em tempos mais recentes, vimos o processamento passar da CPU para a NIC, como o descarregamento da soma de verificação. A Intel também adicionou recursos para ajudar a reduzir ainda mais a carga. Isso é legal e tenho certeza que todos os recursos de otimização estão ativados.

Como você aludiu, jumbo frames - na verdade, isso ajuda na produtividade. Mas não tanto quanto RDMA .

A maioria dos hardwares ethernet de 10 GB terá um recurso subutilizado muito bom chamado RDMA ou acesso remoto à memória direta. Ele permite que a NIC faça memória para cópias de memória pela rede sem a intervenção da CPU. Bem, OK, a CPU informa à NIC o que fazer e, em seguida, a NIC faz o resto. O problema é que não é muito usado ainda. Mas está chegando lá. Aparentemente, na versão mais recente do Microsoft Windows Server 2012, eles têm algo chamado SMB Direct . Ele usa RDMA. Então, se você quiser aumentar o rendimento, você quer usar isso.

Você é capaz de montar algum hardware de teste e instalá-lo lá para ver como ele se comporta?

A propósito, eu não tenho certeza se você vai ver isso em 10Gbit tanto, mas RAM rápida ajuda com RDMA especialmente com Infiniband de 56Gbit. Em geral, é melhor usar a RAM mais rápida que seu servidor suporta.

Observe também este comentário no link SMB Direct que eu coloquei acima:

You should not team RDMA-capable network adapters if you intend to use the RDMA capability of the network adapters. When teamed, the network adapters will not support RDMA.

Atualização: Parece que nem todos os 10GBs suportam RDMA da NIC por algum motivo. Portanto, verifique primeiro os recursos do seu modelo.

Outro pensamento que tive foi o tipo de protocolo que está sendo usado para fazer o seu teste pode estar afetando os resultados. isto é, sobrecarga de protocolo no topo da sobrecarga de TCP. Eu sugiro que você olhe em usar algo que pode testar sem tocar no disco rígido, como iperf. Há uma porta do Windows em algum lugar.

    

Answer 2

Acho que esta pergunta: Por que o meu limite de gigabit não fornece uma taxa de transferência de pelo menos 150 MB / s? está relacionado a seu problema. Eu estava falando sobre um Dell PowerEdge 6950 lá. A resposta foi basicamente "usar quadros jumbo" para reduzir as interrupções. Eu posso imaginar que afinar o mecanismo de descarga da placa de rede pode ajudar no seu caso, mas eu não sei como fazer isso no W2K8R2.

Idéia: Aumente o número de buffers na placa de rede, aumente o trigger de interrupção para os pacotes no buffer, para que cada interrupção manipule mais pacotes (ou seja, passe-os para a pilha OS-IP).

Veja este link: Definindo parâmetros de coalescência com o ethtool para 10 Gb é a isso que estou me referindo basicamente.

    

Answer 3

A captura de tela de utilização da CPU mostra dois possíveis afunilamentos:

1. 4 núcleos maximizando o trabalho do kernel (isto é, provavelmente interrompem os manipuladores processando pacotes)
2. 1 core maximizando o modo de usuário - principalmente -

Para abordar o primeiro:

• Tente alterar as configurações de moderação de interrupção, dependendo de seus drivers, é mais do que apenas ativar / desativar, você pode definir uma estratégia de moderação
• Tente desabilitar / habilitar todos os recursos de descarregamento (no seu caso, desabilitar pode ser benéfico, de modo a mover um gargalo potencial de sua NIC (single-core), para a qual a funcionalidade seria transferida, para seu core) processadores)
• Tente ativar o "Recebimento de Coalescimento" (ao receber o TCP) e os vários recursos "Grande recebimento ...", "Grande transmissão ..." etc. que seu driver pode fornecer
• Você não pode definir suas filas RSS para um valor maior que 4? Parece que apenas uma das suas 2 portas está sendo usada (como você disse que está ciente, eu suponho que você tenha configurado sua segunda porta para pelo menos 4 (ou 8, não tenho certeza se o HT precisa ser contado)
• Se possível, aumente o número de portas TCP / UDP diferentes usadas, ou endereços IP de origem / destino, porque um endereço / porta / protocolo 5-tupla (ou endereço / protocolo 3-tupla para tráfego não-TCP / UDP) sempre terá que ir para o mesmo núcleo, não importa quais sejam suas configurações de RSS

Quanto a este último (não sabendo qual aplicativo você está realmente usando):

Se esse limite de 1 core no modo de usuário indicar o seu aplicativo single-threaded (ou single-thread-necked), ele deve ser

• corrigido ou
• reconfigurado (por exemplo, aumentar # segmentos de trabalho, se possível) ou
• reprojetado

para usar vários núcleos, o que pode ou não ser trivial.

Além disso, como seu aplicativo (se realmente for seu aplicativo), aparentemente é executado em um nó NUMA # 1, mas o manuseio de pacotes pelo kernel é feito no nó NUMA # 0,

• tente afinitar o aplicativo no nó NUMA # 0

Por exemplo clicando com o botão direito no processo no Gerenciador de Tarefas, que lhe dará a opção de alterar isso, pelo menos no Win2012R2. Eu tentei e, para mim, não ajudou, mas vale a pena tentar, pois isso pode melhorar a taxa de acertos do cache.

Btw, a máquina em questão está enviando? Recebendo? Ambos? Em termos de configuração do seu sistema para desempenho, o envio e o recebimento são quase completamente não relacionados, embora minhas sugestões acima cubram ambos.