System Monitor & SQL Profiler como utilizar? – Parte I

Olá pessoal depois de algum tempo sem escrever no blog devido ao inicio das minhas aulas na pós, o MSPTechDay e o S2B vou tentar dar ser mais regular com os pot’s. Hoje vamos falar um pouco sobre System Monitor e  SQL Profiler como combinar as duas ferramentas para resolver problemas dentro do seu servidor.

É muito comum nos dias de hoje enfrentarmos problemas com desempenho  no trabalho ou até mesmo no conforto de nossa casa. Você pode está se perguntando como assim? Imagine a seguinte situação: Uma turma de amigos resolveu marcar um encontro on-line para disputar aquele jogo que acabou de ser lançado. Caso você não tenha uma boa placa de vídeo, memória e um processador mais ou menos a reuniãozinha vai ter que ficar para outro dia. Pois o jogo vai ficar lento, a imagem no seu monitor vai ficar “renderizando” dentre outas coisas.

Falando no mundo do banco de dados, infelizmente vivemos sujeitos a falhas de hardware, bloqueio de transações, paginação, dentre outras coisas que acarretam na degradação das nossas aplicações. Resumindo isso tudo que eu disse é exatamente quando o Service Desk da sua empresa recebe aquelas ligações: “O meu sistema não abre nada!!”, “Tá muito lento não consigo trabalhar” ou melhor “A culpa é da TI”.

Diante dessa situação, vou abordar nesse post como monitorar seu ambiente de SQL Server e a diagnosticar tais problemas através de estudo de caso prático. O desafio é reunir o System Monitor com o SQL Profiler de uma maneira coerente que nos permita fazer uma análise eficiente.

Vou criar um cenário fictício a fim de ajudar na compreensão dos conceitos. Imaginemos que somos funcionários da AdventureWorks e parte das atribuições destinas a nós dentro da empresa, inclui ficarmos encarregados de monitorar o ambiente de produção. Ou seja, verificar o desempenho do banco de dados como um todo. Por exemplo: Analisar se está tendo I/O no disco, como está o processador ou a memória do servidor, quantas conexões estão ativas, e assim por diante.

Ultimamente nosso atendimento nível 01 está recebendo muitas ligações reportando problemas de lentidão com as aplicações. Resolvemos então investigar o motivo dessas reclamações.

O que é o System Monitor?

A primeira coisa que vamos fazer é utilizar o System Monitor, para coletar as informações do servidor de banco de dados. O System Monitor  mostra graficamente os dados em tempo real de desempenho, incluindo a utilização do processador, cache, fila de impressão, sincronização, uso da largura de banda e milhares de outras estatísticas. Ele utiliza uma arquitetura de sondagem para capturar e registrar dados numéricos expostos pelos aplicativos. O DBA escolhe  os contadores a serem capturados para análise de acordo com a análise que ele necessita fazer. No nosso caso vamos escolher os contadores que nos ajudará a identificar o motivo da queda de desempenho nas aplicações.

———————————————————————————————

Nota 1:
A cada nova versão do Windows às vezes você tem que procurar as ferramentas que utilizava anteriormente em um lugar diferente. Porque a Microsoft resolveu mudar o nome da ferramenta ou mudou de lugar. Por exemplo, o System Monitor o pessoal que trabalha com TI há muito tempo conhece esse utilitário como “Perfmon ”, “Performance Monitor” ou “System Monitor”. O nome “Perfmon” foi dado porque umas das formas de iniciar esse programa é acessando o menu iniciar > executar  e digitando na caixa de texto: perfmon.exe.

———————————————————————————————

No entanto para entendermos como obter as informações desejadas é importante compreender os três níveis fundamentais para os critérios de monitoramentos. Estes níveis são: object, counter e instance. Veja a Figura 01.

Figura 01. Contadores de desempenho do Performance Monitor.

  • OBJECT: Um object é um componente, aplicativo ou subsistema dentro de um aplicativo. Por exemplo, Processor, Network Interface e SQLServer:Databases são todos objects.
  • COUNTERS: Counters são um subconjunto de um object. Para um determinado object, você pode ter vários contadores. Por exemplo, o object Processor tem vários contadores para escolher: % Processor Time, % User Time, Interrupts/sec, etc.
  • INSTANCES: Cada counter pode ter uma ou mais instances . Usando o exemplo acima do object Processor, o %Processor Time teria 47 instâncias de um sistema – um para cada processador (0 até 47). Caso necessite, você tem a capacidade de monitorar apenas uma instância de um counter de dados.

———————————————————————————————

Nota 2:
Lembrando que para que os dados sejam coletados corretamente os únicos tipos de dados permitidos pelo System Monitor são numéricos.

———————————————————————————————

Antes de criarmos nosso primeiro Data Collector Sets queria chamar atenção para três contadores em especial. São eles: System: Processor Queue Length, Network Interface: Output Queue Length e Physical Disk: Avg Disk Queue Length. Se identificarmos alguma anormalidade neles, teremos sérios problemas no sistema.

  • System: Processor Queue Length: Este contador, ao invés de avaliar o uso de um único processador, avalia o enfileiramento de threads aguardando oportunidade de execução em todos os processadores. Se ele excede 02 theads por cada processador durante períodos contínuos ou durante um período de monitorização de 24 horas, você poder ter um gargalo de CPU. Por exemplo, se você possui 06 CPU´s no seu servidor, o valor deste contador não deve ultrapassar quanto? A resposta é 12, que equivale ao seguinte cálculo = 06 x 02 = 12. O resultado é a multiplicação de 06 CPU’s com 02 theads(valor aceitável por processador).   Se este valor é ultrapassado por um período muito extenso e constante, pode indicar que seus processadores não estão mais suportando a carga do sistema.
  • Network Interface: Output Queue Length: Este contador de desempenho indica o tamanho da fila de pacotes de saída. Ou seja, é quantos pacotes estão sendo mantidos em uma fila, esperando para ser enviada a partir da placa de rede para rede.  Geralmente esse valor é zero. Como regra geral, se o Output Queue Length for superior a 2 por um período de 10 minutos ou mais de uma vez, provavelmente você tem um problema de desempenho de rede e isso está causando gargalo na rede. As possíveis causas desse problema podem estar em várias coisas como, por exemplo: uma placa de rede lenta, um problema de rede, um problema no hub ou switch, pode ser que o SQL Server é muito, muito ocupado e a carga é demais para placa de rede ou até a própria rede.
  • Physical Disk: Avg Disk Queue Length: Uma thread pode fazer muitos pedidos de uma vez só ao IO Manager(O IO Manager é orientado a pacotes. Resumindo em poucas palavras, sua função é receber os pedidos de leitura/gravação dos processos, transformar estes pedidos em um pacote chamado de IRP – IO Request Packet, e encaminhar este pacote ao driver responsável. Após feita essa operação, o driver devolverá o IRP ao IO Manager com as informações de como foi o processamento) sem esperar que a primeira seja completada.  O IO Manager não irá recusar esses pedidos, mas irá organizá-los numa fila, pois o disco só faz uma coisa de cada vez. O comprimento médio dessa fila é o “Avg Disk Queue Length”. O contador Avg. Disk Queue Length se for superior a dois por períodos contínuos (mais de 10 minutos ou mais durante o período de monitoramento 24 horas) para cada unidade de disco em um array, então você pode ter um gargalo de I/O para esse array. Você precisará calcular este valor, porque o Performance Monitor não sabe quantas unidades físicas estão no seu array. Por exemplo, se você tem um array de 6 discos físicos  e o Avg Disk Queue Length do disco é de 10 para uma disposição particular, então o Avg. Disk Queue Length para cada unidade é de 1,66 (Cálculo: 06/10 = 1,66), que está bem dentro da 2 recomendado por disco físico.

Após a compreensão dos níveis e aprendermos um pouco mais sobre contadores, poderemos em fim criar o chamado Data Collector Sets, que nada mais é do que um bloco de monitoramento onde vamos colocar nossos counters. A grosso modo é um conjunto de dados personalizados onde você decide quais atividades serão monitoradas, mas isso é assunto para o próximo post.

Até a próxima pessoal! =)

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s