Principais problemas de desempenho em nosso SQL Server de produção, como eu solucionaria isso?

11

Esta pergunta é basicamente a pergunta de acompanhamento para esta pergunta:
Problema estranho de desempenho com o SQL Server 2016

Agora fomos produtivos com este sistema. Embora outro banco de dados de aplicativos tenha sido adicionado a este SQL Server desde a minha última postagem.

estas são as estatísticas do sistema:

  • 128 GB de RAM (memória máxima de 110 GB para o SQL Server)
  • 4 núcleos a 2,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
  • Windows Server 2012 R2
  • Versão VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
  • VMware Tools versão 10.0.9, compilação 3917699
  • Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 de outubro de 2016 18:17:30 Direitos autorais (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Standard 6.3 (Compilação 9600:) (Hypervisor)

insira a descrição da imagem aqui

Nosso sistema agora tem grandes problemas de desempenho. Uso muito alto da CPU e contagem de threads: insira a descrição da imagem aqui

Aguarde estatísticas do monitor de atividades (eu sei que não é muito confiável)

insira a descrição da imagem aqui

Resultados de sp_blitzfirst:

insira a descrição da imagem aqui

Resultados de sp_configure:

insira a descrição da imagem aqui

Configurações avançadas do servidor (unfortunalty apenas em alemão)

insira a descrição da imagem aqui

A configuração do MAXDOP foi alterada por mim.

Estou ciente de que isso provavelmente não é um problema com o próprio SQL Server . É provável que seja um problema com a virtualização (vmware), relacionada à rede (eu já testei isso) ou com o próprio aplicativo. Eu só quero prendê-lo ainda mais.

ASYNC_NETWORK_IO alto resultaria em uma alta contagem de threads para o processo sqlserver? Eu imagino que spwan muitos trabalhadores porque os threads não podem ser fechados. Isso está certo?

Fornecerei todas as informações adicionais necessárias. Agradecemos antecipadamente por seu apoio!

EDITAR:

Resultado de sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Prioridade 1: Backup :

  • Fazendo backup na mesma unidade em que os bancos de dados residem - 5 backups feitos na unidade E: \ nas últimas duas semanas, onde os arquivos de banco de dados também estão ativos. Isso representa um risco sério se essa matriz falhar.

Prioridade 1: Confiabilidade :

  • Último bom DBCC CHECKDB com mais de 2 semanas

    • babtec_prod - Último sucesso CHECKDB: 2017-08-20 00: 01: 01.513

    • D3PR - Último CHECKDB bem-sucedido: nunca.

    • DEMO77 - Último sucesso CHECKDB: 2016-02-23 20: 31: 38.590

    • FINP - Último sucesso CHECKDB: 2017-04-23 22: 01: 19.133

    • GridVis_EnMs - Último êxito CHECKDB: 2017-05-18 22: 10: 48.120

    • master - Último CHECKDB bem sucedido: nunca.

    • modelo

    • msdb

    • PROD77 - Último sucesso CHECKDB: 2016-02-23 21: 33: 24.343

Prioridade 10: Desempenho :

  • Repositório de consultas desativado - O novo recurso Repositório de Consultas do SQL Server 2016 não foi ativado neste banco de dados.

    • babtec_prod

    • D3PR

    • DEMO77

    • FINP

    • GridVis_EnMs

Prioridade 50: Eventos DBCC :

  • DBCC DROPCLEANBUFFERS - O usuário schorsch executou DBCC DROPCLEANBUFFERS 1 vezes entre 21 de setembro de 2017 11:57 e 21 de setembro de 2017 11:57. Se essa é uma caixa de produção, saiba que você está limpando todos os dados da memória quando isso acontece. Que tipo de monstro faria isso?

  • DBCC SHRINK% - O usuário schorsch executou o arquivo encolher 6 vezes entre 21 de setembro de 2017 23:51 e 4 de outubro de 2017 9:02. Então, eles estão tentando consertar corrupção ou causar corrupção?

  • Eventos gerais - 287 eventos do DBCC ocorreram entre 19 de setembro de 2017 às 13:40 e 4 de outubro de 2017 às 15:20. Isso não inclui o CHECKDB e outros eventos DBCC geralmente benignos.

Prioridade 50: Desempenho :

  • Crescimentos de arquivos Os crescimentos lentos do PROD77 - 2 levaram mais de 15 segundos cada. Considere configurar o crescimento automático do arquivo para um incremento menor.

Prioridade 50: Confiabilidade :

  • Verificação da página não ideal babtec_prod - O banco de dados [babtec_prod] possui TORN_PAGE_DETECTION para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

Prioridade 100: Desempenho :

  • Muitos planos para uma consulta - 3576 planos estão presentes para uma única consulta no cache do plano - o que significa que provavelmente temos problemas de parametrização.

Prioridade 110: Desempenho :

  • Tabelas ativas sem índices agrupados

    • babtec_prod - O banco de dados [babtec_prod] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

    • D3PR - O banco de dados [D3PR] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

    • DEMO77 - O banco de dados [DEMO77] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

    • FINP - O banco de dados [FINP] possui heaps - tabelas sem um índice em cluster - que estão sendo consultadas ativamente.

    • GridVis_EnMs - O banco de dados [GridVis_EnMs] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

    • PROD77 - O banco de dados [PROD77] possui heaps - tabelas sem um índice em cluster - que estão sendo consultadas ativamente.

Prioridade 150: Desempenho :

  • Chaves estrangeiras não confiáveis

    • babtec_prod - O banco de dados [babtec_prod] possui chaves estrangeiras que provavelmente foram desativadas, os dados foram alterados e a chave foi ativada novamente. Simplesmente ativar a chave não é suficiente para o otimizador usar essa chave - precisamos alterar a tabela usando o parâmetro WITH CHECK CHECK CONSTRAINT.

    • D3PR - O banco de dados [D3PR] possui chaves estrangeiras que provavelmente foram desativadas, os dados foram alterados e a chave foi ativada novamente. Simplesmente ativar a chave não é suficiente para o otimizador usar essa chave - precisamos alterar a tabela usando o parâmetro WITH CHECK CHECK CONSTRAINT.

  • Tabelas inativas sem índices agrupados

    • D3PR - O banco de dados [D3PR] possui heaps - tabelas sem um índice em cluster - que não foram consultados desde a última reinicialização. Essas podem ser tabelas de backup descuidadamente deixadas para trás.

    • GridVis_EnMs - O banco de dados [GridVis_EnMs] possui heaps - tabelas sem um índice em cluster - que não foram consultados desde a última reinicialização. Essas podem ser tabelas de backup descuidadamente deixadas para trás.

  • Gatilhos nas tabelas babtec_prod - O banco de dados [babtec_prod] possui 26 gatilhos.

Prioridade 170: Configuração do arquivo :

  • Banco de dados do sistema na unidade C

    • master - O banco de dados mestre tem um arquivo na unidade C. A colocação de bancos de dados do sistema na unidade C corre o risco de travar o servidor quando ficar sem espaço.

    • model - O banco de dados do modelo possui um arquivo na unidade C. A colocação de bancos de dados do sistema na unidade C corre o risco de travar o servidor quando ficar sem espaço.

    • msdb - O banco de dados msdb tem um arquivo na unidade C. A colocação de bancos de dados do sistema na unidade C corre o risco de travar o servidor quando ficar sem espaço.

Prioridade 170: Confiabilidade :

  • Conjunto máximo de tamanho de arquivo

    • D3PR - O arquivo de banco de dados [D3PR] d3_data_01 possui um tamanho máximo de arquivo definido para 61440 MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_data_idx_01 tem um tamanho máximo de arquivo definido para 61440 MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_firm_01 tem um tamanho máximo de arquivo definido para 61440 MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_firm_idx_01 tem um tamanho máximo de arquivo definido para 61440MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_log_01 possui um tamanho máximo de arquivo definido para 61440 MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_phys_01 possui um tamanho máximo de arquivo definido para 61440 MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_phys_idx_01 tem um tamanho máximo de arquivo definido para 61440MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_sys_01 tem um tamanho máximo de arquivo definido para 20480MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_usr_01 possui um tamanho máximo de arquivo definido para 20480MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_wort_01 possui um tamanho máximo de arquivo definido para 20480MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

    • D3PR - O arquivo de banco de dados [D3PR] d3_wort_idx_01 possui um tamanho máximo de arquivo definido para 20480MB. Se ficar sem espaço, o banco de dados deixará de funcionar, embora possa haver espaço disponível na unidade.

Prioridade 200: Informativo :

  • Padrão da compactação de backup Desativado - Os backups completos não compactados ocorreram recentemente e a compactação de backup não está ativada no nível do servidor. A compactação de backup está incluída no SQL Server 2008R2 e mais recente, mesmo na Standard Edition. Recomendamos ativar a compactação de backup por padrão, para que os backups ad-hoc sejam compactados.

  • O agrupamento é Latin1_General_CS_AS FINP - As diferenças de agrupamento entre os bancos de dados do usuário e o tempdb podem causar conflitos, especialmente ao comparar valores de sequência

  • O agrupamento é SQL_Latin1_General_CP1_CI_AS - As diferenças de agrupamento entre os bancos de dados do usuário e o tempdb podem causar conflitos, especialmente ao comparar valores de sequência

    • DEMO77

    • PROD77

  • Servidor vinculado configurado - BWIN2 \ INFOR está configurado como um servidor vinculado. Verifique sua configuração de segurança quando estiver se conectando com sa, porque qualquer usuário que a consultar receberá permissões em nível de administrador.

Prioridade 200: Monitoramento :

  • Trabalhos de agente sem e-mails com falha

    • O trabalho syspolicy_purge_history não foi configurado para notificar um operador se ele falhar.

    • O trabalho upd_durchpreis_monatl não foi configurado para notificar um operador se ele falhar.

    • O trabalho upd_fertmengen_woche não foi configurado para notificar um operador se ele falhar.

    • O trabalho upd_liegezeit_monatl não foi configurado para notificar um operador se ele falhar.

    • O trabalho upd_vertreter_diff não foi configurado para notificar um operador se ele falhar.

    • O trabalho UPDATE_CONNECT_IK não foi configurado para notificar um operador se ele falhar.

    • O trabalho Wartung.Cleanup não foi configurado para notificar um operador se ele falhar.

    • O trabalho Wartung.DBCC Check DB não foi configurado para notificar um operador se ele falhar.

    • O trabalho Wartung.Index neu erstellen não foi configurado para notificar um operador se ele falhar.

    • O trabalho Wartung.Statistiken aktualisieren não foi configurado para notificar um operador se ele falhar.

    • O trabalho Wartung.Transactionlog Backup não foi configurado para notificar um operador se ele falhar.

    • O trabalho Wartung.Vollbackup SystemDB não foi configurado para notificar um operador se ele falhar.

    • O trabalho Wartung.Vollbackup UserDB não foi configurado para notificar um operador se ele falhar.

  • Não há alertas para corrupção - os alertas do SQL Server Agent não existem para os erros 823, 824 e 825. Esses três erros podem fornecer uma notificação sobre falha de hardware precoce. Habilitá-los pode evitar muitos desgostos.

  • Não há alertas para os dias 19 e 25 de setembro - não existem alertas do SQL Server Agent para os níveis de gravidade 19 a 25. Esses são alguns erros muito graves do SQL Server. Saber que isso está acontecendo pode permitir a recuperação mais rápida dos erros.

  • Nem todos os alertas configurados - nem todos os alertas do SQL Server Agent foram configurados. Essa é uma maneira fácil e gratuita de ser notificado sobre corrupção, falhas no trabalho ou grandes interrupções antes mesmo que os sistemas de monitoramento apareçam.

Prioridade 200: configuração de servidor não padrão :

  • Agent XPs - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1.

  • Database Mail XPs - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1.

  • idioma de texto completo padrão - Esta opção sp_configure foi alterada. Seu valor padrão é 1033 e foi definido como 1031.

  • idioma padrão - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1.

  • nível de acesso ao fluxo de arquivos - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1.

  • grau máximo de paralelismo - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 4.

  • memória máxima do servidor (MB) - Esta opção sp_configure foi alterada. Seu valor padrão é 2147483647 e foi definido como 115000.

  • min server memory (MB) - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 10000.

  • conexões administrativas remotas - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1.

Prioridade 200: Desempenho :

  • limite de custo para paralelismo - Defina como 5, seu valor padrão. Alterar essa configuração sp_configure pode reduzir as esperas do CXPACKET.

  • Ocorrendo backups de instantâneo - 9 backups com aparência de instantâneo ocorreram nas últimas duas semanas, indicando que o IO pode estar congelando.

Prioridade 210: Configuração não padrão do banco de dados :

  • Isolamento de Captura Instantânea Confirmada de Leitura Ativado - Esta configuração do banco de dados não é o padrão.

    • D3PR

    • FINP

  • Disparadores recursivos ativados - essa configuração do banco de dados não é o padrão.

    • DEMO77

    • PROD77

  • Isolamento de instantâneo ativado FINP - Esta configuração de banco de dados não é o padrão.

Prioridade 240: Estatísticas de espera :

  • 1 - ASYNC_NETWORK_IO - 225,9 horas de espera, 143,5 minutos de tempo médio de espera por hora, 0,2% de espera de sinal, 2146022 tarefas de espera, 378,9 ms de tempo médio de espera.

  • 2 - CXPACKET - 43,1 horas de espera, 27,4 minutos de tempo médio de espera por hora, 1,5% de espera de sinal, 32608391 tarefas de espera, 4,8 ms de tempo médio de espera.

Prioridade 250: Informativo :

  • O SQL Server está sendo executado em uma conta de serviço do NT

    • Estou executando como NT Service \ MSSQL $ INFOR. Gostaria de ter uma conta de serviço do Active Directory.

    • Estou executando como NT Service \ SQLAgent $ INFOR. Gostaria de ter uma conta de serviço do Active Directory.

Prioridade 250: Informações do servidor :

  • Conteúdo de rastreamento padrão - O rastreamento padrão contém 760 horas de dados entre 3 de setembro de 2017 às 20:34 e 5 de outubro de 2017 às 12:50. Os arquivos de rastreamento padrão estão localizados em: C: \ Arquivos de Programas \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

  • Drive C Space - 21308.00MB grátis na unidade C

  • Drive D Space - 280008.00MB grátis na unidade D
  • Drive E Space - 281618,00MB grátis na unidade E
  • Drive F Space - 60193,00MB grátis na unidade F

  • Hardware - Processadores lógicos: 4. Memória física: 128GB.

  • Hardware - NUMA Config - Nó: 0 Estado: ON-LINE Agendadores on-line: 4 Agendadores off-line: 0 Grupo de processadores: 0 Nó de memória: 0 Memória VAS reservada GB: 281

  • Última reinicialização do servidor - Okt 1 2017 14:21

  • Nome do servidor - BWINPDB \ INFOR

  • Serviços

    • Serviço: o SQL Server (INFOR) é executado na conta de serviço NT Service \ MSSQL $ INFOR. Última hora de inicialização: 1 de outubro de 2017 14:22. Tipo de inicialização: Automático, atualmente em execução.

    • Serviço: o SQL Server-Agent (INFOR) é executado na conta de serviço NT Service \ SQLAgent $ INFOR. Último horário de inicialização: não mostrado. Tipo de inicialização: Automático, atualmente em execução.

  • Última reinicialização do SQL Server - Okt 1 2017 14:22

  • Serviço SQL Server - Versão: 13.0.4001.0. Nível do patch: SP1. Edição: Standard Edition (64 bits). AlwaysOn Ativado: 0. Status do Gerente AlwaysOn: 2

  • Servidor virtual - Tipo: (HYPERVISOR)

  • Versão do Windows - Você está executando uma versão bastante moderna do Windows: Server 2012R2 era, versão 6.3

Prioridade 254 :undundação :

  • Log do capitão: estrelar algo e algo ...

EDITAR:

Já estudei esse guia de práticas recomendadas em relação à configuração do servidor sql com vmware e definimos a maior parte de acordo com este documento. No entanto, o hyperthreading não está ativado e o NUMA não está ativo no host do vmware. O SQL Server está definido como NUMA.

EDITAR:

Emiti o RECONFIGURE depois de definir o thresold para paralelismo como 50, também minha configuração MAXDOP de não estava configurada.

Também verifiquei com o administrador do vmware, parece que eu estava mal informado. Nossas CPUs estão definidas para 2,6 GHz e não para 4,6 GHz. Corrigi essas informações acima.

EDITAR:

Tentamos definir algumas redes relacionadas de acordo com este vmwarekb e guia . Também adicionamos mais 4 núcleos à VM. O uso da CPU permaneceu o mesmo.

insira a descrição da imagem aqui

insira a descrição da imagem aqui

insira a descrição da imagem aqui

Slot vazio
fonte
Obrigado pela informação de segundo plano. Comece executando sp_Blitz como descrito aqui e colá-lo na sua pergunta: brentozar.com/archive/2009/03/getting-help-with-a-slow-query
Brent Ozar
@BrentOzar, eu adicionei o resultado de sp_blitz ao meu post
Emptyslot
3
OK, más notícias: a resposta ainda é a mesma que a última que você recebeu. ASYNC_NETWORK_IO significa que o SQL Server concluiu o processamento dos resultados da consulta e aguarda a máquina na outra extremidade do canal para digerir os resultados. Veja a resposta original: dba.stackexchange.com/a/186602/426
Brent Ozar
@Emptyslot, verifique se as práticas recomendadas do SQL Server nas VMWare são seguidas: vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/… .
Dan Guzman
Você pode verificar se o plano de energia está definido como alto desempenho e não o padrão (balanceado). Eu já vi muitos problemas devido ao fato de ser padrão.
Kin Shah

Respostas:

18

Conforme discutido na última vez em que você fez essa pergunta , sua principal espera é ASYNC_NETWORK_IO. O SQL Server está aguardando a máquina na outra extremidade do canal digerir a próxima linha de resultados da consulta.

Eu recebi essas informações dos resultados das estatísticas de espera do sp_Blitz (obrigado por colar isso em):

1 - ASYNC_NETWORK_IO - 225,9 horas de espera, 143,5 minutos de tempo médio de espera por hora, 0,2% de espera de sinal, 2146022 tarefas de espera, 378,9 ms de tempo médio de espera.

Não saia da solução de problemas de threads da CPU - isso não está relacionado. Concentre-se no seu tipo de espera principal e nas coisas que causariam esse tipo de espera.

Para solucionar isso ainda mais, execute sp_WhoIsActive ou sp_BlitzFirst (isenção de responsabilidade: sou um dos autores disso) - os quais listarão as consultas em execução no momento. Observe a coluna de informações de espera, encontre as consultas aguardando ASYNC_NETWORK_IO e os aplicativos e servidores dos quais eles estão executando.

A partir daí, você pode tentar:

  • Verificando se esses servidores de aplicativos estão com pouca potência (como se estiverem no máximo na CPU ou paginando em disco) e ajustando-os
  • Trabalhando com os desenvolvedores de aplicativos para verificar se eles estão processando linha por linha nos resultados (como em todas as linhas que retornam do SQL Server, o aplicativo é desativado e faz algum processamento antes de solicitar a próxima linha de resultados)
  • Trabalhando com os desenvolvedores de aplicativos para selecionar menos dados (como menos linhas ou menos colunas, se eles não precisarem de todos os dados) - às vezes você vê isso quando as pessoas acidentalmente fazem um SELECT * e trazem mais dados do que precisavam, ou solicitam todas as linhas quando eles realmente precisam apenas das 1000 principais)

Atualize com sp_WhoIsActive - na captura de tela sp_WhoIsActive que você postou, há algumas consultas aguardando ASYNC_NETWORK_IO. Para aqueles, consulte as instruções acima.

No restante das consultas, observe a coluna "status" de sp_WhoIsActive - a maioria delas está "adormecida". Isso significa que eles não estão funcionando de jeito nenhum - eles estão esperando os aplicativos na outra extremidade do canal enviarem o próximo comando. Eles têm transações abertas (consulte a coluna "open_tran_count"), mas não há nada que o SQL Server possa fazer para acelerar uma transação inativa. Essas consultas estão abertas há mais de quarenta minutos (a primeira coluna em sp_WhoIsActive. Elas não estão mais fazendo nada. Você precisa convencer essas pessoas a confirmar suas transações e fechar suas conexões. Isso não é um problema de ajuste de desempenho.

Tudo o que estamos vendo aqui aponta para um cenário em que estamos aguardando o aplicativo.

Brent Ozar
fonte
Obrigado pela sua resposta. Verificamos os servidores de aplicativos, eles não têm pouca potência. Estamos verificando seus outros pontos. Existem várias instruções que fazem algo como o alias SELECT. * FROM alias da tabela WHERE alias.clumn = value AND CreateDate> = SomeDate. O que não é bonito, mas essas são as mesmas instruções SQL que foram executadas 'sem problemas' com a última versão do nosso sistema ERP (Infor COM 7.1) e com o oracle 9g. Por que a execução piorou com o MS SQL Server e o Infor COM 7.1. Não há declarações que estejam de pé de qualquer maneira. Nosso consultor de ERP verifica tudo o que eu mando.
Emptyslot
1
OK, você precisa começar com a seção marcada "Para solucionar isso ainda mais" - essas são as próximas etapas. Não posso deixar isso mais claro. Obrigado!
Brent Ozar
1
É isso que estou fazendo. Estou enviando as consultas que os dois procedimentos mostram ao nosso consultor.
Emptyslot
@Emptyslot bem, você sabe como é, não pode confiar nesses consultores. ;-)
Brent Ozar
5
@Emptyslot - esta será a última vez que eu responder, a menos que você coloque o que já pedi três vezes: execute sp_WhoIsActive ou sp_BlitzFirst (aviso de isenção: sou um dos autores disso) - os quais listarão as consultas que estão sendo executadas atualmente. Isso também inclui sua conexão SSMS e mostra o que está esperando. Por favor, entenda que estou oferecendo meu tempo aqui para ajudá-lo, e fui educado, mas a polidez pára por aqui: FAÇA O QUE EU PEDI PARA VOCÊ TRÊS VEZES.
Brent Ozar
2

Para responder minha própria pergunta. ASYNC_NETWORK_IO na verdade não era o problema real. Corrigimos nosso problema de desempenho seguindo este guia para cargas de trabalho sensíveis à latência:

Práticas recomendadas para ajuste de desempenho de cargas de trabalho sensíveis à latência nas VMs do vSphere

Marquei as configurações que aplicamos ao nosso sistema com a cor amarela aqui:

insira a descrição da imagem aqui

Acho que as configurações com maior impacto foram a configuração de numa e a sensibilidade da latência para alta . Quais ambos, explicitamente, alocam / reservam núcleos físicos da CPU e RAM para a VM.

Também adicionamos mais núcleos à VM e agora precisamos atualizar nossa licença do SQL Server do Standard para o Enterprise.

Slot vazio
fonte
1
Obrigado por compartilhar seus detalhes de resposta. Também estamos executando o SQL no Vsphere e talvez seja necessário revisar essas opções caso ocorram problemas. Por favor, mantenha esta resposta. Lamento que alguém tenha marcado com você. +1
Sting
Você ajustou esses ajustes somente para o SQL Server ou também / somente para o aplicativo?
Eckes
Também ajustamos o servidor de aplicativos com essa configuração. Também estamos considerando ajustar nossos desktops virtuais com a configuração de latência para média / normal. Meu palpite é que isso iria resolver os nossos problemas em relação async_network_io
Emptyslot
1

Parece que o Windows está relatando a velocidade do clock de seus núcleos de CPU adequadamente de 4,6 GHz como 2,6 GHz ... Eu executaria uma ferramenta como a CPU-Z para verificar em qual velocidade eles estão realmente executando e depois alterar as configurações de energia em o Windows e o BIOS / OS de gerenciamento para desativar as configurações de economia de energia que podem limitar os núcleos a uma velocidade mais baixa.

Milney
fonte
Eu estava mal informado, os núcleos da CPU estavam em 2,6 GHz o tempo todo. Não há nenhuma configuração de economia de energia ativa, nem no host nem no convidado.
Emptyslot
Eu examinaria mais de perto o aviso 'Tabelas ativas sem índices de cluster'. Se você tem grandes montes que estão sendo ativamente consultados que vai matar o desempenho mal ...
Milney
Infelizmente, havia apenas uma tabela que não possui índice de cluster. Possui duas colunas, uma das quais é NVARCHAR e a outra do tipo de dados IMAGE. Ele já tinha um índice exclusivo não clusterizado para a primeira coluna. Também adicionei um índice em cluster. Mas isso não ajudou muito.
Emptyslot