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:
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:
Ele mostra mais segundos do tempo de espera para ASYNC_NETWORK_IO do que os segundos em que sp_blitzfirst foi executado.
fonte