Quando um usuário ou aplicativo faz solicitações a um banco de dados, ele consome recursos desse sistema. À medida que o número de solicitações aumenta, você pode enfrentar esperas de recursos. Essas esperas levam a gargalos de desempenho e, no caso de bancos de dados implantados na nuvem, custos mensais extras! Ao diagnosticar gargalos de desempenho, a primeira etapa é entender quais recursos são afetados.
Ser capaz de mapear um gargalo de desempenho de volta para uma espera de recurso específica, depois para um código específico e, finalmente, para a carga de trabalho de um usuário específico permitirá que você chegue à causa raiz e resolva o gargalo permanentemente.
Por exemplo, você pode descobrir que um aplicativo está lento porque a CPU está sendo consumida em excesso no servidor de banco de dados porque Matt, no departamento de compras, está executando um relatório de estoque no banco de dados da planta.
O Workload Analyzer do Spotlight Cloud é a ferramenta que torna isso possível com sua navegação amigável.
Como usar o analisador de carga de trabalho do Spotlight Cloud
Para começar, você pode selecionar o período de tempo de seu interesse. O Spotlight Cloud armazena um ano de dados, para que você possa voltar a qualquer ponto no tempo ou intervalo de tempo no ano passado.
Então você tem a opção de filtrar por recurso. Por exemplo, se você sabe que o problema está relacionado à CPU, você pode selecionar o recurso CPU. Isso filtra as informações relacionadas a todos os outros recursos, como E/S, bloqueios e memória, eliminando efetivamente o ruído branco e tornando mais fácil chegar à causa raiz.
Página padrão do Workload Analyzer
Aprofunde-se na dimensão de bancos de dados e ele ordenará os principais bancos de dados que consomem mais recursos de alto a baixo e os sombreará de forma correspondente. Esse mecanismo de classificação é preservado em cada iteração de uma pesquisa detalhada.
Aprofundando na dimensão do banco de dados
Além disso, você deve detalhar o banco de dados de vendas porque é importante saber qual é o comportamento das esperas especificamente no banco de dados de maior consumo. Neste exemplo, parece que a maior parte da carga de trabalho foi contabilizada pela CPU (45,7%) e recursos de E/S (30,2%), e suas taxas estão próximas de 0,48 seg/s e 0,43 seg/s.
Aprofundando na dimensão do banco de dados de vendas
Em paralelo, a seleção da CPU filtrará os outros recursos e produzirá uma leitura personalizada somente da CPU. A capacidade de isolar uma carga de trabalho específica é útil porque exclui visualmente as métricas de distração, permitindo que você se concentre apenas no que tem precedência. Além disso, os indicadores de desempenho podem ser representados graficamente uns sobre os outros para que você possa ver as correlações visualmente.
Indicadores-chave de desempenho filtrados apenas para estatísticas de CPU
Em seguida, analise os lotes T-SQL. Isso nos permite descobrir quais lotes no banco de dados de vendas são os mais exigentes.
Aprofundando nos lotes T-SQL
Como esse lote consome muita CPU, é importante saber quais consultas nesse lote são responsáveis pelo custo extra. Usar o texto T-SQL em conjunto com o plano de execução mostra que o operador Sort é o culpado. O SQL Optimizer prevê que a cobrança estimada é de 97%. Adicionar um índice pode ajudar a otimizar o desempenho.
Instruções T-SQL
Plano de Execução e Análise de Custos das Operações Realizadas
Observe que o seletor de recursos pode ser configurado para destacar um recurso quando sua utilização violar um limite predefinido. Por exemplo, você pode definir o seletor para destacar recursos de E/S se a espera for superior a 30 por cento.
Ajustando as configurações do seletor de recursos para recursos de E/S
Configurações atualizadas para o seletor de recursos de E/S aplicado
