Problema estranho de desempenho com o SQL Server 2016


14

Temos uma única instância do SQL Server 2016 SP1 em execução em uma máquina virtual VMware. Ele contém 4 bancos de dados, cada um para um aplicativo diferente. Esses aplicativos estão todos em servidores virtuais separados. Nenhum deles ainda está em uso de produção. As pessoas que testam os aplicativos estão relatando problemas de desempenho.

Estas são as estatísticas do servidor:

  • 128 GB de RAM (memória máxima de 110 GB para o SQL Server)
  • 4 núcleos a 4,6 GHz
  • Conexão de rede de 10 GBit
  • Todo o armazenamento é baseado em SSD
  • Arquivos de programa, arquivos de log, arquivos de banco de dados e tempdb estão em partições separadas do servidor
  • asd

Os usuários estão realizando acesso em tela única por meio de um aplicativo ERP baseado em C ++.

Quando eu estressei o teste do SQL Server com a Microsoft ostressusando muitas consultas pequenas ou uma consulta grande, obtive desempenho máximo. A única coisa que limita o cliente é o cliente, porque ele não pode responder rápido o suficiente.

Porém, quando quase não existem usuários, o SQL Server não está fazendo nada. No entanto, as pessoas precisam esperar para sempre apenas para salvar qualquer coisa no aplicativo.

De acordo com a consulta " Diga-me onde dói " de Paul Randal , 50% de todos os eventos de espera são ASYNC_NETWORK_IO.

Isso pode significar um problema de rede ou desempenho com o servidor ou cliente de aplicativos. Nenhum deles está usando remotamente seus recursos na capacidade máxima. Na maioria das vezes, a CPU é de cerca de 26% em todas as máquinas (cliente, servidor de aplicativos, servidor db).

A latência da conexão de rede é de cerca de 1-3ms. O IO do servidor db atinge a velocidade máxima de gravação de 20 MB / s durante o uso normal com o aplicativo (a média é de 7-9 MB / s). Quando realizo o teste de estresse, consigo um máximo de 5 GB / s.

O tamanho do cache do buffer é de 60 GB para o banco de dados do nosso sistema ERP, 20 GB para o nosso software de financiamento, 1 GB para o software de garantia de qualidade e 3 GB para o sistema de arquivamento de documentos.

Dei à conta do SQL Server o direito de usar a Inicialização Instantânea de Arquivos . Isso não aumentou o desempenho nem um pouco.

A expectativa de vida da página é de aproximadamente 15k + durante o uso normal. Cai para cerca de 0,05k durante o final dos testes de estresse intenso, o que é esperado. Lotes / s é de cerca de 2-8k, dependendo da carga de trabalho.

Eu diria que o aplicativo ERP está mal escrito, mas não posso porque todos os aplicativos são afetados. Mesmo com carga de trabalho mínima.

No entanto, não consigo identificar o que está causando isso. Existem dicas, tutoriais de dicas, aplicativos, documentos de práticas recomendadas / melhores práticas ou qualquer outra coisa que vocês tenham em mente sobre esse problema?

Estes são os resultados de sp_BlitzFirst:

insira a descrição da imagem aqui

insira a descrição da imagem aqui

Eu corri 600 segundos. Eu o iniciei durante uma alta carga de trabalho do aplicativo. 1/3 do tempo é ASYNC_NETWORK_IO. Também testei a conexão de rede com NTttcp, PsPing, ipferf3, e pathping. Nada incomum. Os tempos de resposta são no máximo 3 ms, média 0,3 ms. O rendimento é de cerca de 1000 MB / s.

Minha investigação sempre resulta em ASYNC_NETWORK_IOser a número de espera número um.

Investigamos o resultado da desativação do Large-Receive-Offloadrecurso no VMware. Ainda estamos testando, mas os resultados parecem inconsistentes. Nosso primeiro 'benchmark' resultou em uma duração de 19 minutos (o resultado principal é 13 minutos, o que é alcançado apenas quando o aplicativo está sendo executado na VM com o próprio SQL Server). O segundo resultado é 28 minutos, o que é muito ruim.

O primeiro resultado do nosso 'benchmark' foi de 19 minutos. Qual é bom. Porque o resultado principal foi 13 minutos (o que é possível apenas quando o aplicativo faz benchmarks na VM com o próprio SQL Server). Isso sugere fortemente algum problema relacionado à rede. Ou um problema com a configuração do VMware.

Atualmente, estou perdido em quais métodos usar, para prendê-lo ao gargalo.

O desempenho máximo com o aplicativo só é possível quando o aplicativo está sendo executado na VM com o próprio SQL Server. Se o aplicativo for executado em qualquer outra VM ou desktop virtual, a duração do nosso benchmark triplicará (de 13 minutos para 40 minutos ou mais). Todos os pontos de extremidade (VM do SQL Server, VM do servidor de aplicativos e a Área de trabalho virtual) estão usando o mesmo hardware físico. Movemos todos os outros pontos de extremidade para outro hardware.

EDIT: Parece que o problema está de volta. Depois de definir o modo de economia de energia de equilibrado para alto desempenho, na verdade aprimoramos dramaticamente os tempos de resposta. Mas hoje eu executei o sp_BlitzFirst novamente, com uma amostra de 300 segundos. Este é o resultado:

Esse é o resultado

Ele mostra mais segundos do tempo de espera para ASYNC_NETWORK_IO do que os segundos em que sp_blitzfirst foi executado.

Respostas:


18

Se a sua espera principal for ASYNC_NETWORK_IO, o problema não está no SQL Server. É quase sempre devido a um gargalo de aplicativo. Não quero dizer um gargalo no servidor de aplicativos, mas um gargalo no aplicativo.

O gargalo do aplicativo geralmente ocorre devido ao processamento linha a linha enquanto o SQL Server envia os dados:

  • O aplicativo está solicitando dados do SQL Server
  • O SQL Server está enviando os dados rapidamente
  • O aplicativo está dizendo ao SQL Server para aguardar enquanto processa cada linha
  • O SQL Server registra o tempo de espera ASYNC_NETWORK_IOenquanto o aplicativo está pedindo para aguardar

Em vez disso, o aplicativo precisa consumir todos os dados do SQL Server e, em seguida, faz o processamento linha por linha. O SQL Server está fora de cena nesse momento.

sp_BlitzFirst resultado

A LCK_M_Sespera não é alta. Apenas 2 segundos da amostra de 30 segundos estão nela e sua média é de apenas 400ms. É muito, muito improvável que seja esse o problema. ASYNC_NETWORK_IOé a sua principal espera nessa amostra. Ainda é um problema de aplicativo. Se você quiser ajuda com o LCKmaterial, precisaremos ver as consultas envolvidas.

Mesmo ASYNC_NETWORK_IOnão é tão ruim nessa amostra. Meus olhos ficam grandes quando o tempo de espera é igual ou superior ao tamanho da amostra. É quando eu entro.

Todo o seu problema é ASYNC_NETWORK_IO. Este não é um problema do SQL Server. Há um problema com o aplicativo (executando o processamento linha a linha enquanto o SQL Server envia os dados), o servidor de aplicativos (você já disse que está tudo bem) ou a rede (você disse que a rede está bem). Portanto, o problema está no aplicativo. O aplicativo C ++ precisa ser corrigido.


6

Para responder à minha própria pergunta: O principal motivo para o ASYNC_NETWORK_IO aparecer no nosso SQL Server como o tipo de espera superior, foi que a energy savingconfiguração do servidor Windows foi definida como em 'balanced'vez de 'high performance'. Depois conversamos com alguns administradores de software vm ware, e todos disseram que essa configuração prejudica o desempenho .

As soluções para isso são:

  • Não instale o controle de energia ao instalar o servidor Windows
  • Defina o modo de economia de energia como alto desempenho para todos os servidores via diretiva de grupo

Todas as outras questões / estatísticas relacionadas ao ASYNC_NETWORK_IO estão relacionadas ao mau uso do nosso aplicativo ERP. Obrigado a todos que me ajudaram a resolver esse problema, seus comentários, sugestões e conselhos foram muito bem-vindos e úteis!


Muitos BIOSs têm agora um controle mais granular da economia de energia, por exemplo, gerenciamento de energia da NIC. Gostaria de saber se ainda é possível ter a escala de frequência ativada e evitar as esperas de E / S na NIC, desativando apenas seus modos de economia de energia.
23918 Ajeh
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.