windws server 2008 udp problema de desempenho multicast

Question

Encontrei um problema de desempenho estranho no 2008 R2 Enterprise SP1.

Aqui está a configuração:

• Muitos processos ouvindo streams multicast UDP distintos (5 multicasts escute por processo) ligado a um único NIC
• Entre os processos, todos os multicasts usando o mesmo intervalo de portas, mas diferentes IPs multicast (detalhes importantes, já que cada receptor multicast para uma determinada porta será o servidor do soquete do servidor REUSED)
• Cada largura de banda de multicast de processo é de 10Mbits
• Conjunto de RSS na NIC, configurações de descarga máxima definidas em NIC & OS, MSI ativado

Comportamento:

• Em 17 processos de audição (cerca de 85 se juntaram a Multicast UDP), Kernel O impacto da CPU é negligenciável.
• entre 17 e amp; 22 ouvintes (cerca de 110 se juntaram Multicasts UDP), o uso da CPU do kernel começa a crescer lentamente, mas é aceitável
• Acima de 25, cada multicast associado começa a ter um impacto enorme no tempo de CPU do Kernel, isso afeta todas as CPUs ligadas ao RSS
• O tempo de CPU usado por processo de escuta está próximo de 0 (normal, já que os processos não fazem nada além de ler o multicast), então o problema real está em o componente do SO

O que encontramos:

• Alterar o hardware da NIC não tem impacto no comportamento (testado no HP NC382i, NIC & HP NC365T, Quad Gigabit, baseado em Intel)
• A largura de banda de recebimento global não é o fator limitante (fluxo único de 500Mbits não aciona a carga da CPU)
• A leitura no soquete multicast parece não ser o fator limitante (nós executou o teste com apenas JOIN apenas processa os fluxos de multicast e reproduz o problema de carga da CPU)
• A divisão do tráfego Multicast em duas NICs parece limitar a carga da CPU & espalhar Melhor. No entanto, este não é um caso de uso para nós.

Problema:

• Precisamos pelo menos ser capazes de ouvir cerca de 500 fluxos de multicast e talvez até 750
• O mesmo hardware, executando o XP OS, não tem esse comportamento no Kernel da CPU tempo

Componente procurado:

O
• NDIS.sys parece ser um bom candidato para explicar o aumento do uso da CPU.

Algum de vocês encontrou tais problemas e poderia dar alguma orientação para investigar. Eu li tudo o que pude sobre como ganhar o aprimoramento de desempenho de rede do servidor 2008, mas todos parecem estar ligados ao tráfego TCP. Também testei todas as otimizações possíveis que poderiam ser feitas por meio do registro ou do comando netsh.

    

Answer 1

Isso é um monte de fluxos de multicast, normalmente os NICs têm um limite baixo para filtragem de hardware e quando você ultrapassa isso, eles descartam tudo (implementação deficiente em NICs baratas) ou encaminham tudo para o sistema operacional para filtragem. Quando o sistema operacional está executando a filtragem, seu uso do processador está indo para o foguete do céu.

Além de investigar hardware diferente, que você lista alguns, você pode estender para 10GigE também, a única opção é usar servidores proxy.

Por experimentação, encontre vários fluxos de multicast que podem ser gerenciados de forma confiável e, em seguida, encaminhe os fluxos via TCP para um servidor central ou um conjunto de servidores. Esse servidor central pode usar aceleração de segmentação TCP ou ToE completo para tornar a carga de entrada da rede insignificante para o processador.

Não consigo obter taxas de multicast decentes com o hardware da Broadcom devido a drivers muito ruins do Windows. Seria interessante ver como o Linux funciona no mesmo hardware, isso deve lhe dar uma boa indicação do hardware e da qualidade da pilha IP.

Você lista o Windows XP como funcionando bem, a principal diferença entre o Windows Server e o Windows XP é o tempo quântico. O Windows Server fornece tempos quânticos mais longos, pode valer a pena investigar forçar um quantum mais curto (se você puder configurá-lo).