Estou procurando uma ferramenta para medir ou detectar "falta de resposta" de um PC de mesa

4

Eu tenho um cliente que fornece alguns sistemas de servidor para um hospital, e foi levantado um ticket de suporte que o aplicativo da área de trabalho estava aguardando pelo servidor. Fizemos alguns testes extensivos e ficou claro que o servidor é responsivo, e a rede está bem, e que o problema está no lado do cliente. (nenhum pedido é recebido durante o travamento, etc ...)

Vamos dar uma olhada nas máquinas desktop e elas devem ficar bem, então nós aumentamos os tickets com o fornecedor do software que diz que deve ser o hardware, a empresa de hardware diz que é o software, etc etc

De qualquer forma, conversando com as enfermeiras, elas dizem que essas máquinas geralmente "ficam suspensas" por 30 segundos por vez e, às vezes, durante momentos importantes em que precisam obter dados para um paciente que não está bem, como gráficos e status .

Portanto, quero colocar um cliente nessas máquinas que possa detectar "falta de resposta" arbitrária do teclado / mouse e registrá-lo para análise posterior.

Obviamente, tenho receio de sugerir alguma aplicação que tome recursos e agrave ainda mais o problema, por isso estou interessado em ver quaisquer ferramentas que possam detectar esses problemas (é correto dizer que as interrupções do teclado estão sendo descartadas?) procurando o sistema operacional descartando as interrupções, ou o que for apropriado aqui.

então, vá em serverfault, aqui está sua chance de salvar uma vida ....; -)

Edit: Estou começando a pensar que algumas das ferramentas associadas a sistemas em tempo real podem ser apropriadas, pelo menos como um diagnóstico.

Pense nisso como o ônibus espacial. Uma vez que a coisa é lançada, é isso. Sua lançado e você está preso com o que está instalado. Portanto, não há gerenciamento remoto das máquinas às quais tenho acesso e não posso me sentar e examinar os logs. Todos os casos teriam que ser resolvidos antes. (Meu pensamento é que se eu pudesse "detectar" falta de resposta, então eu poderia acionar um VBscript para copiar os arquivos de log relevantes e métricas de desempenho em um arquivo, e ter uma tecnologia local para passar esses arquivos)

    
por Tom H 04.10.2012 / 17:16

2 respostas

3

Isso exigiria a modificação do aplicativo cliente, mas você poderia adicionar chamadas a ele para postar e assistir a chamadas para o servidor e contar para a resposta. Isso forneceria a você um meio de estabelecer linhas de base e estabelecer máquinas com um padrão de problemas, ou se uma máquina ou o aplicativo, de fato, não responde.

O

Grafite é especialmente bom para isso.

Por outro lado, se é o próprio desktop que é o problema, não conheço melhor maneira de detectar falta de resposta do que uma combinação de um usuário e seu número de telefone direto.

(Por definição, o sistema não saberá que é lento ou que não responde.)

    
por 04.10.2012 / 17:23
2

Esta é uma batalha sem fim. Empresa de hardware acusa a empresa de software ... que culpa a equipe de TI ... que culpam ... ... ... ... < YEAH OUTSOURCING! >

Infelizmente, "enforcamento" pode ser causado por tantas coisas diferentes por muuuuuuuuuuuuitos motivos diferentes. Não existe uma ferramenta mágica que possa monitorar todas as causas possíveis de "tempo de espera". Tanto quanto o que você pode fazer ... é usar a ferramenta "perfmon" embutida no Windows, e adicionar diferentes contadores de desempenho que você está interessado .... o que pode ser qualquer coisa. (sim, você pode monitorar máquinas remotas) Comece com o básico ... como o uso da CPU, os comprimentos de fila do Disco Físico, a utilização da rede, etc ...

Se você perceber uma grande quantidade de uso da CPU ... é hora de descobrir o que o aplicativo está fazendo e por que ele está consumindo muita CPU.

Se você vir um número significativo de coisas esperando na fila de disco ... talvez você deva otimizar seu disco (defrag? substituir por unidades de disco mais rápidas? verificar erros ... etc ...) Se você estiver Ainda sem sorte aqui ... talvez o aplicativo não esteja muito bem otimizado. Desenvolvedores ruins frequentemente cometem erros quando o aplicativo lê 100mb de dados quando precisa apenas das últimas 5 linhas de um log.

Se você está vendo uma grande quantidade de tráfego na rede ... é hora de descobrir o motivo. Talvez haja um monte de "re-transmissões" devido a cabeamento / hardware com defeito ... talvez a rede tenha um loop, e os switches não suportam spanning-tree ... Talvez haja muito lixo excessivo na rede como impressoras habilitadas para apple-talk / ipx ... a lista continua.

Você pode precisar dar um passo além e implementar algo como o wire-shark e monitorar a troca de pacotes entre o cliente e o servidor. Talvez o aplicativo envie um pacote para o servidor e espere (bloqueie) por uma resposta antes de continuar a execução do programa. Talvez o próprio servidor esteja sobrecarregado e não consiga acompanhar o número de conexões de clientes.

... isso é apenas um arranhão na superfície ... Solucionando problemas de "suspensão" de aplicativos quando você não tem acesso ao código-fonte ou a um desenvolvedor que sabe o que está fazendo ... é uma ENORME empresa.

    
por 04.10.2012 / 17:38