Eu tenho um servidor dual core, 4 GB de RAM, executando o Windows Server 2008 que uso como servidor de arquivos principal.
O acesso a ele de repente tornou-se muito lento. Quer eu faça RDP ou acesse arquivos remotamente por meio de unidades mapeadas, é apenas lento!
Posso fazer RDP em outras máquinas localizadas em outro estado pela VPN e elas funcionam muito mais rápido.
Se estou trabalhando diretamente no próprio servidor, é rápido. Parece que é algo entre minhas máquinas clientes e o servidor.
Como eu verificaria a velocidade da conexão de rede entre as duas máquinas? Ou qualquer outra coisa que eu deva verificar?
Responder1
Eu vi muitos switches de rede baratos "enlouquecerem" no último ano ou assim. O modo de falha são transferências super lentas e quedas de pacotes. (Eu vi isso principalmente com switches LinkSys no ano passado). Eu suspeito disso, embora não necessariamente como a primeira coisa. Felizmente, um teste de velocidade simples é muito fácil com "Compartilhamento de arquivos e impressões".
Você pode fazer um teste "rápido e sujo" para a taxa de transferência do servidor de arquivos criando um arquivo temporário grande no computador cliente com o comando fsutil e cronometrando a transferência para o computador servidor:
fsutil file createnew temp-file-name 209715200
Isso criaria um arquivo temporário de 200 MB. Você pode fazer uma cópia rápida com tempo usando o seguinte script (do diretório onde você criou o arquivo temporário e supondo que você tenha direitos para copiar para algum compartilhamento no computador servidor):
@echo off
echo.|time
copy temp-file-name \\server-computer-name\share-name
echo.|time
Subtraia o horário final do horário inicial, converta para segundos e divida 209715200 pelo número de segundos decorridos para obter bytes por segundo.
Você deverá ver mais de 7.000.000 bytes por segundo (aproximadamente 56 Mbps) em uma LAN 100Base-TX. Qualquer coisa abaixo disso e eu começaria a suspeitar que algo está acontecendo. Supondo que o computador servidor seja razoavelmente moderno, ele deverá ser capaz de preencher um canal de 100 Mbps sem problemas. Se você observar velocidades de transferência mais lentas do que isso, começaria a observar os contadores de erros na interface de administração do switch ao qual o servidor e o cliente estão conectados. Você pode ter cabeamento defeituoso, incompatibilidade duplex ou problemas de driver da NIC. É tudo apenas uma questão de rastrear o problema metodicamente.
Editar: O teste de cópia de arquivo é um bom teste porque você pode conduzi-lo sem qualquer software de terceiros. Como você descobriu que existe um gargalo, a próxima etapa é identificar a causa do gargalo.
O utilitário WSTTCP (disponível emhttp://www.pcausa.com/Utilities/pcattcp.htm) é um teste rápido e sujo do driver da NIC e do hardware da infraestrutura de rede. Ele envia dados que não saem do disco ou são gravados no disco, de modo que os subsistemas de disco no cliente e no servidor acabam sendo excluídos da equação.
Em uma máquina, execute o seguinte (depois de descompactar o WSTTCP!) para "ouvir" uma conexão:
wsttcp -r
Na outra máquina, execute o seguinte para transmitir um teste à máquina remota:
wsttcp -t <hostname>
Na Ethernet de 100 Mbps, você pode querer modificar o comando de transmissão (executando novamente o comando de recepção no receptor antes de iniciar o transmissor novamente) para enviar mais buffers, porque você obterá números um pouco mais precisos com um teste mais longo:
wsttcp -t -n8192 <hostname>
Isso movimentará 64 MB de tráfego. Aumente o número “8192” para enviar mais tráfego.
Você precisará permitir o ouvinte através do software de firewall no computador ouvinte (porta TCP 5001, por padrão) ou desabilitar o firewall temporariamente.
Se você observar boas velocidades de transferência com o WSTTCP, mas transferências lentas com a cópia do arquivo, comece a examinar o subsistema do disco (e considere executar um benchmark da unidade de disco rígido). Se as transferências de rede ainda estiverem ruins com WSTTCP, continue investigando a infraestrutura de rede, o cabeamento, os drivers da NIC ou o hardware da NIC.
Boa caçada.
Responder2
Uma coisa que eu recomendaria é verificar se há vírus, etc. Execute o netstat para ver as conexões abertas e dê uma olhada para ver se algo é duvidoso/inesperado. Provavelmente existem ferramentas para testar a largura de banda entre duas máquinas Windows, mas não conheço nenhuma. iperf poderia funcionar no cygwin.
Responder3
Execute um comando tracert no PC de destino para ver onde está o atraso. Isso lhe dará estatísticas detalhadas sobre cada salto.
sintaxe, por exemplo: tracert 196.12.2.13
Responder4
Talvez isso também seja parte do problema?