windows server 2003 speed issues

Question

Eu tenho um servidor HP com Windows Server 2003 e 50 clientes Windows XP.

Desde uma semana e meia, a velocidade das redes cai repentinamente 2-3 vezes por dia. Ele fica tão lento que nenhum dos clientes poderia trabalhar com o programa HIS instalado neles.

Nós tentamos muitas coisas diferentes, como substituir os hubs, switches e até mesmo alguns fios. Toda vez que uma dessas mudanças resolve o problema, a rede volta ao seu estado normal.

Eu verifiquei tudo. Mesmo quando desconectei todos os clientes do servidor e os conectei a apenas um computador, o problema ainda permanecia por duas horas.

Eu apenas reduzi o problema ao par de especulações prováveis da seguinte forma:

1. vírus? (O Kaspersky atualizado em execução no servidor não mostra nenhum)
2. falha de hardware do servidor?
3. Uso de memória física no servidor? (Porque a última vez que o problema ocorreu nenhuma das mudanças acima resolveu o problema, então eu reiniciei o servidor e verifiquei o uso de memória física que foi de 2 GB. Mas eu notei que está aumentando ao longo do tempo para mais de 9 GBs ... o servidor tem 16 GB de RAM.)

Eu naveguei na internet e não consegui nada. Qualquer ajuda nos faria muito .... obrigado antecipadamente

    

Answer 1

Em última análise, você precisa saber o que o servidor está fazendo quando o problema é aparente e o que o servidor está fazendo quando está tudo bem.

Além de dizer que a rede está indo devagar, você não dá pistas sobre como o servidor está respondendo.

Quando você diz que a rede está indo devagar, você quer dizer que o aplicativo cliente está sendo executado lentamente, falando com o servidor, ou você realmente quer dizer que as respostas de pacotes estão demorando muito?

Meu plano de ação seria:

1. Confirme se o hardware do servidor está OK. Se você tem o pacote de suporte ProLiant (PSP) instalado, navegue até https: // yourservername : 2381 (você tem isso instalado, certo?). Logon usando uma conta com admins privs e verifique o estado do seu hardware
2. Verifique a configuração da (s) sua (s) placa (s) de rede. Veja que tipo de latência de ida e volta você tem entre o servidor / cliente (do cliente, execute ping -t servername ).
3. Verifique os logs de eventos (particularmente o log do sistema) - execute o eventvwr.exe
4. Verifique o espaço livre em suas unidades. Descubra onde estão seus arquivos de paginação e quão grandes eles são. Considere fragmentar suas unidades.
5. Use o monitor de desempenho para examinar:

a) Disco físico - duração média da fila do disco (queira que seja < = 2)

b) Disco físico -% de tempo de disco (não quero que isso seja constantemente > 80%)

c) Processador -% de tempo do processador (não quero que isso seja constantemente > 80%)

d) Interface de rede - bytes enviados / seg

e) Interface de rede - bytes recebidos / seg

f) Memória - leituras de páginas / seg

6) Finalmente, um nível um pouco mais baixo, mas as ferramentas Process Monitor e Process Explorer da Systems Internals (agora da Microsoft) são fantásticas para fornecer uma visão do que realmente está acontecendo em um servidor

--- 10/09/2012

Assim, o servidor está saudável e respondendo OK (pode usar a área de trabalho remota e "usá-lo"). A razão para enfatizar esse ponto é que o Windows Server não manipula muito bem a privação de recursos do kernel. O Linux começa a matar processos quando o kernel é ameaçado, mas a MS ainda não se acostumou com essa ideia. Quando os recursos do kernel estão fora do limite (pools não paginados, Etc), os servidores do Windows podem simplesmente parar de responder ... até que algo libere um recurso de memória do kernel. Não ter um arquivo de paginação suficientemente grande (ou arquivos) pode acelerar a privação de recursos em servidores ocupados. Meus próximos passos seriam:

• Verifique os contadores SQL no perfmon (como sugere Hennes)
• Veja como o SQL está respondendo no servidor quando você está tendo problemas (você pode executar consultas básicas do SQL Management studio?)
• Verifique a configuração do seu servidor SQL (memória e parâmetros da CPU)

Answer 2

Problema resolvido! Ele estava vindo do tamanho irrestrito do nosso arquivo de log do banco de dados sql.Nosso servidor tem uma unidade de disco rígido de 2 TB e por padrão sql define a opção AutoGrow para qualquer banco de dados criado para 10% da capacidade do HDD.Neste caso, nosso arquivo de log foi para ser 200 GB e essa foi a razão pela qual a velocidade da rede caiu a cada 6 ou 7 nosso (erro SQL 5144) .porque? Porque toda vez que os clientes solicitam uma consulta e uma mudança para o DB vai ser logado pelo sql server tem que escrever no arquivo de log e colocar zero para o resto do tamanho do arquivo de log e isso faz com que o problema.Para resolver isso, restringimos o tamanho a 10 MB para o arquivo de log e Problem Solved ... muito obrigado a Simon e Hennes pela sua resposta.