slow unc resolution em uma ação win 2008

Question

Eu tenho alguns problemas com o meu servidor sbs 2008. Basicamente, se eu tentar acessar os compartilhamentos do servidor através de um caminho unc, levará um longo tempo para ser resolvido, mas uma unidade mapeada é rápida (até eu tentar abrir um arquivo, muitas vezes pode ser lento).

Esse comportamento ainda acontece na própria máquina, se eu tentar acessar seus próprios compartilhamentos por meio do caminho unc, por exemplo

\servername\share\ 

Copiar para ele ou para ele, uma vez aberto, é mais rápido do que nunca, e o comportamento é periódico - fica por um tempo pensando, então tudo explode na vida e é rápido, depois de um tempo ele fica lento novamente.

Coisas a serem observadas:

1) Eu não tenho proteção contra vírus (desinstalei quando comecei a ter problemas). 2) É totalmente corrigido. 3) Eu verifiquei o interruptor por pings contínuos e não perdi nenhum. 4) Eu tentei desabilitar cópias de sombra sem efeito. 5) Nenhum backup está sendo executado.

- editar

informação adicional

1) macs não parecem ter problemas com compartilhamentos

2) a troca tem problemas - entourage diz que tem problemas para copiar um email para uma pasta enviada em um mac

3) O servidor possui uma NIC Broadcom BCM5708C NetXtreme II

4) O TCP chimeny agora está desativado, assim como o descarregamento da soma de verificação está desativado, a carga grande de desligamento está desativada. O TOE está ativado no cartão, mas não pode ser desativado, a menos que eu o ative no Windows, eu acho.

5) usando o endereço IP não ajuda.

    

Answer 1

Você está usando o Symantec Enterprise Security 11? Há um problema com 2008 e compartilhamentos de servidor em versões mais antigas atualizadas; Não tenho certeza se esse é o seu problema, mas algo para investigar se você estiver usando a Symantec (não vi nenhuma declaração sobre o software de A / V).

link

Eu notei esse problema no meu primeiro servidor de arquivos de 2008 depois que cerca de 20/30 usuários começaram a usá-lo. Ficou progressivamente mais lento, então, finalmente, desistiu de compartilhar arquivos, mas tudo o resto (RDP, etc.) funcionou bem. Depois de rasgar o cabelo, descobri que era o problema de A / V mencionado acima.

    

Answer 2

Você tem uma NIC Broadcom no servidor e o mecanismo de transferência de TCP está ativado? Esta é uma configuração conhecida por causar problemas, então certamente vale a pena verificar e desabilitar o mecanismo de descarregamento, se necessário.

    

Answer 3

O que acontece se você usar o endereço IP em vez do nome:

 \11.22.33.44\share

Este é um domínio do Windows e você está usando acidentalmente servidores DNS externos, talvez do seu provedor de Internet - em vez de seu (s) controlador (es) de domínio?

    

Answer 4

Meu pensamento inicial é que é um problema de resolução de nome ou um problema de autenticação. A unidade mapeada em ambos os casos já fez as duas coisas.

Coisas para experimentar:

1. Conecte-se via IP \ 172.16.0.1 \ Share ou \ 172.16.0.1. \ Share - é mais rápido
2. Primeiro, conecte-se ao \ Servidor e, em seguida, quando o \ Server \ Share for conectado mais rapidamente?

Se o primeiro problema, verifique se as máquinas clientes estão usando o servidor DNS interno como seu servidor principal.

Se o segundo problema verificar os logs de eventos no servidor para qualquer coisa relacionada ao controlador de domínio.

    

Answer 5

Eu tive um problema semelhante e tentei todos os itens acima & mais, mas nenhum funcionou até que eu desliguei Firewall do Windows 2008, agora o compartilhamento é realmente nippy :)

NB: Nosso firewall de rede protege o sistema win2008

    

Answer 6

Uma outra coisa veio à minha mente. Algumas semanas atrás, havia essa pergunta aqui no ServerFault.com:

Desativar os locais de rede do Windows Server

My problem is that sometimes some network adapters decide they are now on a public network. This completely activates the firewall, even for the "domain" networks. So net effect is that I reboot some machines, and then they never come back on the network until we KVM in and tell it that the network is private.

Talvez este seja o seu problema também.

    

Answer 7

você achou. E quanto ao protocolo smb 2.0? Se você acessar um win2008 a partir de um winxp, eles concordam com o smb 1.0, por outro lado, se você acessar com um winvista, ele deve usar o protocolo smb 2.0. Isso poderia explicar esse comportamento.   Gelo

    

Answer 8

Eu tive um problema semelhante ao ter machine1 IIS com sua página inicial apontada para \ machine2. Transferências muito lentas pelo site. Eu desliguei o SMB2 como esta página mostra, e isso resolveu o problema.

link

    

Answer 9

Eu tive esse problema na consulta UNC de servidores da Web para documentar servidores no grupo de trabalho dos servidores Windows 2008 e 2012. A primeira chamada do dia poderia levar mais de 60 segundos, as chamadas subseqüentes eram cerca de 200 mSecs. Resolveu o problema desativando o TCP / IPv6 nas NICs internas.