Diagnosticando o processamento lento de dados em uma VM

Question

Estamos tentando diagnosticar uma VM aparentemente em execução lenta, de dentro da VM.

A situação:

• Temos um aplicativo hospedado pelo IIS no Windows Server 2008 R2 executado em uma máquina virtual de 6 núcleos e 12 GB.
• Temos um banco de dados em execução em um cluster do SQL Server 2008R2 SP3 (mais de 16 núcleos, > 16 GB de RAM)
• O aplicativo está processando uma fila de mensagens nesse banco de dados. O processamento consiste principalmente em consulta / busca e atualização, talvez cerca de uma dúzia de viagens por mensagem. Um número limitado de encadeamentos (3) é designado a essa carga de trabalho, que é síncrona, portanto, os encadeamentos bloqueiam as respostas do banco de dados.
• O banco de dados é aparentemente pouco carregado: apenas alguns por cento da carga máxima da CPU.
• Até onde sabemos, o banco de dados e o host da VM estão no mesmo datacenter.

O banco de dados relata um tempo considerável gasto esperando em E / S de rede assíncrona, ou seja. esperando que o aplicativo consuma dados. A aplicação VM também é aparentemente levemente carregada: ~ 20% da CPU. A infraestrutura não é de nossa propriedade e nosso único acesso é via RDP para a máquina virtual e o SQL Management Studio para o cluster de banco de dados. Não temos privilégios suficientes para executar um profiler, embora registremos contadores de desempenho para o banco de dados e a VM.

Há algumas semanas, a taxa de processamento de mensagens caiu abruptamente em 70-80%. Até onde sabemos, nada mudou: o aplicativo não foi modificado ou reconfigurado, e os contadores de desempenho não indicam nenhuma mudança nas características de carga. Os proprietários da infraestrutura afirmaram que nada mudou no final.

Como parte de um processo de reinicialização, o aplicativo foi feito para recarregar sua fila de mensagens. Isso envolve um SELECT simples de algumas centenas de milhares de linhas que são então lidas em estruturas na memória. O banco de dados atendeu o SELECT em alguns segundos, mas depois esperou ~ 10 minutos no aplicativo lendo o conjunto de resultados. Esta é uma operação single-threaded envolvendo desserialização muito simples, e não deve demorar mais do que alguns minutos neste hardware.

Minha teoria atual é que a latência de rede aumentou de alguma forma, mas o ping registra apenas "< 1ms" e não temos uma linha de base em nenhum caso. hrPing relata tempos entre 0,5 e 2ms do servidor de aplicativos para o banco de dados.

Outra possibilidade é que a capacidade real da CPU da VM tenha diminuído de alguma forma, mas eu esperaria que isso se manifestasse como uma carga 'aparente' aumentada.

Existem outras vias de investigação disponíveis para nós?

    

Answer 1

Obrigado por todas as sugestões! A situação acabou sendo resolvida, embora não tenhamos sido informados se era o host da VM ou a rede que estava se comportando mal, nem exatamente o que foi feito para consertá-la.

No processo de solução de problemas, escrevemos um aplicativo simples para definir o perfil de determinadas operações do banco de dados e tentamos identificar a maneira exata em que a plataforma não era sensata:

link

Basicamente, o statistics time de 0ms reivindicado 0ms transcorreu enquanto ocasionalmente o cliente SQL tinha certeza que tinha gasto algumas centenas de milissegundos esperando que ExecuteReader () retornasse, apontando para um problema de rede ou possivelmente uma VM faminta de timeslices . Esses picos afetam cerca de 5% das viagens de ida e volta do banco de dados e dão às operações normalmente instantâneas uma alta probabilidade de levar vários segundos para serem concluídas.

Um dos técnicos do cliente compilou e usou a ferramenta pessoalmente. Ele confirmou nossas descobertas e as encaminhou para a equipe apropriada, e algumas horas depois o problema foi resolvido.

Parece, de fato, que era, como todos suspeitavam, um problema de rede!

    

Answer 2

Eu não sou nenhum especialista, mas aqui estão meus 2 centavos:

1) Elimine dúvidas:

Faça duas transferências de pasta grande do banco de dados para o servidor de aplicativos e o contrário para cerca de 500 MB. 1 A pasta deve conter um único arquivo binário com 500 MB de tamanho. A segunda pasta deve conter milhares / milhões de arquivos no 1KB ou menos e ver o desempenho da rede para cada caso. O primeiro irá mostrar-lhe uma simulação de baixo fluxo de carga payload contagem de pacotes, o segundo (que irá imitar as transações de banco de dados) irá mostrar-lhe uma simulação de alto fluxo de payload baixa contagem de pacotes. Isso lhe dará uma idéia de que tipo de ambiente de rede eles têm disponível e se suas preocupações com a rede são verdadeiras. Tenha em mente que a capacidade de comutação não é apenas a velocidade da porta. 10 MB / s chegando em 10 pacotes NÃO é a mesma carga no switch (troca de utilização da CPU) como 10 MB / s chegando em 100.000 pacotes ... O switch tem que transferir cada pacote independentemente da carga útil e você pode obter saturação da rede facilmente se você não tiver capacidade de comutação suficiente (pacotes por segundo). Agora, provavelmente (99,9%) não será o caso em um data center, mas você nunca saberá com certeza até que você teste

2) Configuração do aplicativo de 2º ponto:

Espero que este seja o seu aplicativo e você o tenha configurado corretamente. Se não, a maioria dos drivers JDBC tem Transações em Lote, o que às vezes, se explicitamente definido em seu provedor de persistência, pode causar um comportamento semelhante ao seu (o aplicativo está aguardando uma certa quantidade de gravações antes de realmente confirmar uma transação ou aguardar por um número de leituras antes de executar a consulta). Mesmo assim, essas operações em lote têm timeouts que estão na ordem de um segundo ou 2, então, eles confirmam as transações, se a fila em lote está cheia ou não

3) Impressão fina do Contrato de Terceira Nuvem:

Agora, como este é um provedor de nuvem, verifique a boa impressão. O tipo de transação a que você está se referindo envolverá um grande número de transações no Host Bus. A maioria dos provedores agora limita a utilização de barramento por VM, mas eles não anunciam exatamente (você encontrará um limite no gt / s). Portanto, quando os dados estão chegando, há um enorme impacto na transferência da interface de rede através do barramento para a RAM de suas VMs (lembre-se de que suas VMs não são compatíveis com recursos, portanto, elas não estão obtendo os mesmos compartilhamentos e, portanto, carga de trabalho de rede varia). Um bom indicador de que você está sendo limitado é ter uma conexão 1G, tentando transferir um grande arquivo contíguo binário localmente sem carga e nunca atingindo 50 ~ 60 MB / s (450-480 Mbps)

De qualquer forma, espero que ajude