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

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)

Nosso sistema agora tem grandes problemas de desempenho. Uso muito alto da CPU e contagem de threads:

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

Resultados de sp_blitzfirst:

Resultados de sp_configure:

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

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.

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.

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:

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.

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.