Monitoramento de performance com Perfmon

A nossa demanda por serviços cresce de maneira acelerada. Em um cenário em que cada vez mais temos aplicações web e na nuvem, o desempenho de códigos e máquinas é testado à exaustão a todo o momento e cada microssegundo conta quando o assunto é performance.

Não é estranho dizer que para o usuário final, principalmente o de um sistema web, tudo que demora menos de um segundo é rápido, e o que passa disso já gera a necessidade de um novo clique. Manter esse tipo de usuário satisfeito é um desafio diário e mesmo o mais simples software, aquele que não damos atenção por imaginar que não existe complexidade, pode gerar gargalos de desempenho no servidor. Porém, quando voltamos nossa atenção para sistemas de altíssima disponibilidade e escalabilidade, como internet bankings, nosso problema pode estar em outro nível de análise.

É exatamente sobre isso que abordaremos nesse artigo. Passaremos pelos contadores básicos de análise de um ambiente SQL e posteriormente listaremos alguns contadores importantes para uma análise mais minuciosa de performance no servidor SQL Server. Por fim, conheceremos o Performance Monitor e teremos uma ideia de como tratar as informações geradas por ele.

Iniciando a análise

Ao iniciar um trabalho de performance, devemos em primeiro lugar ter em mente que existem alguns pontos a serem descartados antes de explorarmos muito a fundo nosso ambiente. Além de sair testando configurações de SQL, parâmetros de instalação, eventos de espera e habilitando traces para identificar códigos que possam estar prejudicando sua aplicação, é interessante que você descarte inicialmente os indicadores básicos quando o assunto é desempenho.

Quando nosso computador pessoal começa a ficar lento, as primeiras coisas que nos vêm à cabeça são o processador e a memória. No caso dos servidores de bancos de dados não é muito diferente, com o adendo de mais dois itens muito importantes para análise, a Rede e os Discos.

Embora isso possa parecer desnecessário em um universo de servidores dedicados e máquinas cada vez melhores, muitos problemas de performance se dão por um mau dimensionamento do ambiente ou mau aproveitamento de seus recursos.

Dito isso, quando iniciamos um trabalho de análise de ambiente, os primeiros itens a serem testados são memória, CPU, disco e redes. Iniciaremos então com os contadores de memória.

Memória

Ao analisar a memória, incialmente podemos levar em consideração dois contadores. O primeiro é o Memory\Available bytes. O threshold para esse contador é de 80% e devemos ficar atentos a mudanças abruptas em seus valores. Quedas no percentual de memória utilizada podem indicar reinicializações da instância.

Junto com o Memory\Available bytes, devemos observar o comportamento do disco onde fica o arquivo de paginação de memória. Para essa análise utilizamos o contador % Busy Time. Um alto consumo do disco de paginação pode indicar pressão por memória. Números acima de 5% já podem ser tratados com maior atenção. Para esse contador, podemos definir um limite de 10%.

Available bytes é o contador que nos diz quanto de memória está disponível no servidor. Para identificar o quanto de memória a máquina está utilizando basta subtrair da memória total.

Assumindo que falamos de um servidor dedicado de banco de dados, sabemos que o SQL, se não limitado pelas configurações, utilizará toda a memória disponível. Dessa maneira não é novidade se nos depararmos com um gráfico onde a memória utilizada fica estável acima dos 90%. Essa é a hora de relacionar a memória com outro contador, o % Busy Time.

Se for iniciada uma coleta padrão do performance monitor, sem que haja qualquer interferência ou sem que seja feita alguma configuração específica, haverá um contador desse para cada disco do nosso servidor. Como sabemos que o consumo de memória em um servidor dedicado é elevado, o nosso foco é no disco onde está o arquivo de paginação. Ao analisar os indicadores de consumo de memória, podemos nos deparar com um gráfico que apresente indicadores altos. É nesse momento que devemos relacionar essa informação com o disco onde se encontra o arquivo de paginação. Se os números para esse contador estiverem baixos, significa que o servidor não precisou utilizar-se do arquivo de paginação, ou seja, a memória pré-alocada do SQL Server está sendo o suficiente para que ele realize todas as suas tarefas.