Monitore o consumo de recursos do banco de dados


Todo mundo gosta de otimização de performance, por isso, inventei 9 regras para ajudar as pessoas a melhorarem os conhecimentos sobre o assunto. Gostaria de começar falando sobre a Regra 1, que fala sobre monitorar o consumo de recursos.

image

Logo que escrevi essa regra, pensei em duas coisas:

  • As pessoas ficarão curiosas para saber por que coloquei a palavra DISK, quando os recursos deveriam incluir CPU, memória e rede.
  • Ao ler a regra, a expectativa das pessoas será encontrar os contadores do Perfmon ou DMV’s para usar no dia a dia.

Por isso, gostaria de propor o seguinte desafio:

Você é capaz de dizer se o banco de dados está sofrendo lentidão usando somente os contadores do Performance Monitor?

Segue aqui as informações do Performance Monitor:

  • Processor
    • %Processor Time = 65%
  • System
    • Processor Queue Length = 5
    • Context Switches/sec = 27000
  • Logical Disk
    • Average Disk Queue Length = 13
  • Memory
    • %Committed Bytes In Use = 48%
    • Available MB = 220
    • Page Faults/sec = 4000
  • SQL Buffer Manager
    • Page Life Expectancy = 140
    • Buffer cache hit ratio = 92%
    • Lazy Writer/sec = 0.5
  • SQL General Statistics
    • User Connections = 5200
  • SQL Statistics
    • Batch Requests/sec = 1000
    • SQL Compilations/sec = 70

No próximo artigo vou comentar um pouco mais sobre a análise do Performance Monitor.

Comments (6)

  1. Thiago Caserta disse:

    Resposta simples: Sim.

    Resposta mais completa:

    Há algumas informações que precisaríamos saber, por exemplo, quantidade de CPU, # de spindles, etc.

    Mas olhando os contadores vs thresholds, diversos deles indicam situações interessantes e uma possível lentidão.

    %Processor Time não indica um problema, mas 27k context swhitches talvez, aí cai na questão de quantos processadores a máquina possui, já que o valor ideal recomendado é de no máximo 10k por CPU.  

    Aparentemente há um infileramento de disco, mas aí entre outro detalhe, sem saber como está a latência não dá pra dizer com certeza. Você mesmo me ensinou, você pode estar numa fila, mas se a fila anda rápido, você talvez nem sinta tão frustrado assim. Por isso, se a latência for baixa, pode ser que o enfileiramento nem seja um problema, mas mais uma vez, se olharmos os thresholds, existe uma tolerância de até 2 operações de I/O por disco físico (spindle) e sem saber o # de spindles não consigo dizer com 100% de certeza.

    Agora, vamos falar de memória, e eu sei que você gosta de sacanear. Hahaha

    Dá pra perceber claramente que o SQL Server está acessando constantemente o disco já que aparentemente não há memória suficiente no Buffer Pool para manter as páginas por muito tempo (140 PLE tá de sacanagem). Juntando isso ao Cache Hit Ratio de 92% dá pra perceber que o SQL precisa acessar mais constantemente os discos pra satisfazer as consultas. Agora, o %Committed Bytes In Use é um pouco misleading, já que ele considera o paging file, se você tem uma área de Paging File gigante, esse percentual é teoricamente baixo, porém você pode estar sofrendo sem memória RAM, e consequentemente utilizando Paging File, que é disco e é um problema. Dado o cenário, sem olhar waits e outros contadores que me ajudariam a embasar minha teoria, eu diria que o SQL pode estar sofrendo uma pressão externa/interna por memória, e aí temos sim uma lentidão, basicamente causada pelo constante acesso a disco. Mas como sei que suas questões são geralmente mais tricky, vou aguardar a sua explicação! Hahaha

    Abraços mestre!

  2. fcatae disse:

    Boa análise. Não posso comentar muito senão vira um spoiler dos demais artigos… posso dizer que voce foi bem certeiro em relação ao disco. Abraços Fabricio

  3. Luiz Mercante disse:

    Interessante essa hein! O Thiago falou tudo, uso bastante o Perfmon e Lazy Writer/sec é algo que praticamente não se vê. Neste caso, poderíamos pensar que o cache havia sido zerado recentemente mas média de 0,5 é bastante perto do que estou habituado a ver, geralmente 0,0X. Temos algum enfileiramento de disco mas não sabemos quantas Disk Transfers/sec estamos fazendo e se são de escrita ou leitura. Também não temos o Sec/Transfers pra saber a latência. Agora o Cache Hit Ratio estou acostumado a ver valores bem próximos de 99,9%, mesmo quando o PLE está baixo. Pior que não dá nem pra aumentar max server memory com 220MB free. Estou acompanhando, abs!

  4. fcatae disse:

    Olá Luiz! Obrigado pelo seu palpite. Também estou acostumado a ver muitos 9 no Cache Hit Ratio. Abraços, Fabricio

  5. Jorge disse:

    Apesar de concordar com boa parte do que foi dito pelo Thiago e pelo Luiz, minha resposta seria não. Não sou capaz de dizer pois o que temos é um "snapshot" e precisaria olhar por mais alguns segundos e verificar se os valores se mantinham.

    Mas eles são interessantes… Processor Queue Length com valor acima de 0 já é um forte indicativo de que a demanda por processamento não está sendo atendida, naquele momento…

    O Avg. Disk realmente parece ser ruim, mas (como já mencionaram em outras palavras) 13 mil transfers/sec a 1 ms/transfer  ou 130 transfer/s a 100 ms/transfer nos dariam o valor 13… Eu concluiria, é que neste momento o disco esteve bastante ocupado…

    Em suma, considerando os contadores de memória, posso dizer que o servidor esteve bem ocupado naquele instante, e se o dado que estava tentando acessar não estivesse em cache, provavelmente as 1000 requisições daquele segundo podem ter sofrido esperando um pouco por disco, que esteve bem ocupado.

    Bom post! Aguardando demais!

  6. fcatae disse:

    Oi Jorge! Concordo com você que o snapshot é muitas vezes (nesse caso também) incompleto para uma análise. Achei legal os complementos que voce adicionou. Obrigado!

    Fabricio

Skip to main content