Compartilhamentos de arquivos do Hyper-V em uma ampla Ethernet drasticamente mais lenta

Question

Recentemente, movemos uma máquina de compartilhamento de arquivos que é executada em 2008 hyper-v para nosso data center a partir de nossa rede local e agora é periodicamente extremamente lenta.

As redes estão conectadas via ethernet ampla. O ping do servidor retorna em menos de 1 ms e o tracert mostra apenas 1 salto novamente em menos de 1 ms. Outros serviços fornecidos a partir desse local parecem não ser afetados (DC, Active Directory, intranet, etc.)

1 1 ms < 1 ms < 1 ms 192.168.XX.XX

Diferente do local, nada mais mudou no servidor, incluindo o endereço IP.

Uma planilha de excel simples pode levar até 2 minutos para ser baixada. Navegar pelas ações também pode ser lento.

Alguma idéia?

    

Answer 1

Mais coisas do que simples latência do TCP podem retardar o desempenho do servidor Windows. Se você é capaz de fazer isso, jogue um sniffer como o Wireshark em um cliente que experimente o carregamento lento de planilhas do Excel e veja como ele fica na tela. Talvez você veja tempos limites suspeitos entre pacotes, como intervalos estranhos de 200 ms entre pacotes. Em seguida, compare o tráfego semelhante a uma máquina não afetada sem VM para ver como deve ficar.

Configurações do driver de rede. Quando você se mudou para o HyperV, inevitavelmente você alterou o driver da NIC. As configurações aqui podem afetar o tráfego de maneiras que o ping não pode diagnosticar ou expor. Coisas como essa são melhor expostas pelo que você está fazendo: copiar arquivos do sistema, criar conexões, navegar por compartilhamentos. Mesmo que tenha mudado de um ponto-rev do HyperV para outro, as versões do driver podem ser ligeiramente diferentes.

Mas os fluxos de pacotes devem lançar mais luz sobre os problemas.

    

Answer 2

Algumas coisas para verificar:

Determine se o MTU é menor do que o esperado para uma Ethernet normal. Da estação de trabalho do cliente:

ping -f -l 1472

Se ele retornar "O pacote precisa ser fragmentado, mas o DF setado" (ou "pedido expirou"), continue reduzindo de 1472 até você determinar qual é a carga útil máxima. O MTU é carga útil máxima mais 28 bytes (8 bytes para cabeçalho ICMP + 20 bytes para cabeçalho IP, Ethernet MTU normal é 1500).

Em seguida, no Wireshark e no MS Network Monitor 3.3, você pode adicionar a coluna "Comprimento do Frame". Isso permitirá que você veja se o servidor está enviando quadros Ethernet de tamanho grande. Crie um filtro de exibição ou captura para pacotes > 1514 bytes, no entanto, o servidor realmente não deve enviar pacotes maiores que o MTU.

Se houver quadros grandes, eles serão determinados pelas propriedades do adaptador de rede "Large Send Offload" e "Jumbo Packets" em seu convidado.

    

Answer 3

Há boas sugestões já feitas que valem a pena investigar. Outro problema comum que enfrentei foi o descarregamento TCP Chimney, especialmente com as placas de rede Broadcom. Tente desativá-lo e testar para ver se está entrando em jogo. link