Um pouco mais de Perfmon, Contadores de Performance, O que monitorar?

Publicado em:
11/01/2011

Fonte: Fábio Augusto

Em um consultório, o médico solicita alguns exames quando o paciente reclama de algum problema de saúde. De fato, é impossível para o profissional adivinhar a solução para um problema sem antes levantar algumas informações. Um exame de sangue, por exemplo, analisa alguns indicadores cujos valores devem estar enquadrados em uma faixa de valores aceitáveis para serem considerados saudáveis.

No computador não é muito diferente. Quando algo está errado, uma coleta de indicadores é necessária antes da solução do problema. Estes poderiam ser:

  • Entrevistar o usuário que reclama de um problema. Ele é uma fonte de indicadores, não?
  • Levantar logs, sejam do Event Viewer ou de aplicações.
  • Análisar contadores de performance.
  • Utilizar ferramentas de debug como o Kernel Debugger e o Debug Diagnostics.

E outros indicadores.

Neste post, vamos colocar nossos esforços na análise dos contadores de performance. Vamos ver quais são os indicadores de performance mais expressivos para as situações mais comuns. Como o perfmon já mudou de nome inúmeras vezes (de Performance Monitor no Windows NT a Reliability and Performance Monitor no Windows Vista/Windows 2008), vamos nos referir a ele apenas pelo seu executável, cujo nome permaneceu imutável: perfmon. Nosso trabalho será nele. Abra o perfmon e vamos lá.

Obs.: Embora meu objetivo principal seja fornecer um bom conteúdo em português, procuro manter a referência dos termos em inglês para que o leitor possa aprofundar o tema utilizando os documentos oficiais do fornecedor ou de terceiros, muito mais numerosos na lingua inglesa. Os nomes dos contadores serão expostos em inglês e, posso ou não, oferecer uma tradução no texto, até porque não costumo utilizar o Windows em português no ambiente profissional, que é constituído, exclusivamente, de servidores. A tradução para o português é bastante simples e é uma obrigação do profissional de TI ter alguma familiaridade com esta língua.

Vamos começar pela grande vedete. Quando falamos de problemas de performance, logo vem à cabeça o processador.

Processor/% Processor Time

O contador % Processor Time é o preferido quando o assunto é avaliar a utilização do processador. Ao abrir o perfmon, ele já está lá, por padrão. Embora o contador exiba a situação do processador, ele deixa de informar o quanto o processador está ocupado de fato. Para medir o uso do processador (ou dos processadores em conjunto), eu recomendo o próximo contador.

System/Processor Queue Length (Comprimento da Fila do Processador)

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. Ele é o melhor indicador para avaliar o estado real do(s) processador(es). Regra geral, 2 threads para cada processador é um valor aceitável. Acima disto, pode pensar em um upgrade ou avaliar o que está usando tanta CPU e otimizar quando for possível. Por que este indicador é melhor que o % Processor Time? Se você tiver um processador com 99,9999% de utilização, mas não tiver enfileiramento, não há problema. Este cenário não é comum, mas exemplica bem a importância do monitoramento da fila.

Agora vamos ver a memória. É comum ver por aí especialistas em memória, mas será que estão olhando nos lugares certos? Vamos dar uma olhada em alguns contadores de performance relacionados ao uso da memória. Como no caso do processador, os mais populares não são os mais expressivos.

Memory/Available MBytes

Este contador, MBytes Disponíveis, mostra única e exclusivamente a quantidade de memória física (hardware) disponível. A alocação de memória física é controlada pelo Memory Manager e, pouca memória física disponível, não significa problema em todos os casos. Quando este valor está muito próximo de 0, é necessário observar outros valores antes de incriminar a memória.

Memory/Commited Bytes

O contador Bytes Comprometidos (esta é a tradução do Windows, embora pareça estranha quando descobrimos para que serve) indica qual é a quantidade de memória virtual em uso. O seu limite, denominado Commit Limit, é a soma da memória física (hardware) com a soma dos arquivos de paginação (pagefiles) configurados no sistema. Este é um contador importante e é útil quando queremos determinar se precisamos instalar mais RAM ou quando queremos saber se o pagefile está configurado corretamente. O valor deve ser igual ou inferior, tanto quanto possível, à quantidade de memória física instalada. Em outras palavras, se você tem 2GB de memória, um pagefile de 2GB e 3GB de bytes comprometidos, significa que o seu Windows está ocupando 1GB de memória virtual no disco (3GB comprometidos – 2GB físicos instalados). A idéia é que o Windows utilize pouco o pagefile, porque o pagefile está no disco e o disco é lento.

Mas, quanto é muito? Não dá para dizer olhando apenas este contador a menos que a desproporção seja evidente, como 2GB de memória física e 4GB de Commited Bytes. Este contador levanta apenas a suspeita.

Antes de fazer o churrasco, vamos salgar a carne:

Quando uma página de memória não está residente na memória física e uma thread tenta acessá-la, esta thread é bloqueada e uma interrupção de hardware ocorre. Isto é chamado page fault. Para a resolução da paged fault, a página procurada deve ser resgatada de volta para a memória física e aí começa o problema.

Existem dois tipos de page faults: hard page fault e soft page fault. Aqui é comum encontrarmos um problema de conceito. Muitos profissionais adoram monitorar o contador Memory/Page Fault/sec. O problema com este contador é que ele mostra todas as page faults, soft e hard (No Windows Vista e 2008, os hard faults são exibidos por padrão quando abrimos o Reliability and Performance Monitor) . Todos nós amamos a soft page fault, que nada mais é do que dizer que a página estava no cache, ou seja, em memória. É a page fault do bem. Nós não gostamos é da hard page fault, pois esta ocorre quando a página está no disco.

Então faz sentido olhar quanto há de cache. Se tem bastante cache, as page faults, quando ocorrerem, poderão vir do cache ao invés do disco. Você pode verificar este valor olhando na tab Performance do Task Manager ou usando kernel debugger. Com o debugger, você vai obter os valores exatos das listas de memória, que é um assunto para outro post.

Além de olhar o cache, você pode verificar se a performance do disco está sendo afetada, nosso próximo contador.

De forma geral, quando o cache e a memória física estão baixos, e o Commited Bytes alto, você precisa instalar mais RAM.

Vamos ver os discos.

Physical Disk/% Disk Time

Sempre que monitorar o disco, utilize o objeto Physical Disk. Afinal, você quer saber se o disco todo está comprometido. Outra recomendação. Não utilize este contador. Ele tem um problema sério. Apesar de ser uma porcentagem, ele passa de 100% quando o disco está muito ocupado, pois ele é a soma de outros contadores. Confie em mim e esqueça este contador para sempre. Tá, não precisa esquecer. Apenas lembre de não utilizá-lo.

Physical Disk/% Idle Time

Este pobre contador, ignorado por muitos, é um dos melhores contadores para avaliar a performance do disco. Ele foi introduzido no Windows 2000 e mede, simplesmente, a porcentagem de tempo em que o disco não está fazendo nada. Podemos concluir que seu inverso é, de fato, o tempo de uso do disco. Lembre-se deste contador e utilize-o em conjunto com o próximo.

Physical Disk\Current Disk Queue Length

Na mesma linha do Processor Queue Length, este contador mede a quantidade de requisições aguardando atenção do disco. É o contador mais importante para avaliar contenções no disco, na minha opinião. Ele pode e deve ser utilizando em conjunto com o % Idle Time. Vale a mesma regra geral do processador: para cada disco, 2 requisições. Isto é apenas um parâmetro de comparação.

Tome cuidado ao avaliar este contador quando o disco estiver em um storage. Você nem sempre sabe quantos discos físicos estão compondo um disco lógico. Lembre-se de dividir o valor observado pelo número de discos físicos para ter uma idéia melhor do que está ocorrendo.

Não vamos falar da rede aqui. Não é comum ter problemas de banda na maioria dos ambientes. É mais comum observar erros na configuração das interfaces de rede ou problemas causados por drivers desatualizados. Pode haver necessidade de uma análise mais apurada em ambientes que envolvam replicação de arquivos pela rede, video ou grande acesso concorrente de usuários. Vamos tratar deste tema em outro post.

Estes são os principais itens para uma primeira análise de um ambiente com problemas de performance. Quando uma alteração é detectada em um dos indicadores, é necessário aprofundar a análise naquela área utilizando outros contadores ou ferramentas.

Lembrando que sempre devemos monitorar o Servidor , mas não somente quando ele realmente apresenta problemas,  é sempre bom avaliar o seu ambiente e para que ele trabalhe saudável.
Se quiser mais dados, baixem este documento, aqui estão os 4 principais itens a serem monitorados.
Fica ai a dica,
[  ]’s
Anúncios

Avaliando o desempenho do seu servidor

Publicado em:
04/01/2011

Visão Geral:
 
 

Avaliando o desempenho do seu servidor

 
Visão geral:
  • Como personalizar o Desempenho do Sistema
  • Diretrizes sobre o que medir e com que freqüência
  • Uma visão geral dos principais contadores e do que procurar

 

 Imagine que você acaba de chegar ao escritório em uma manhã de segunda-feira e é recebido por um usuário ansioso, reclamando da lentidão de seu servidor. Por onde começar para ajudá-lo?
O Desempenho do Sistema, uma ferramenta muito útil incorporada ao Windows®, pode ajudá-lo a diagnosticar o problema.Você pode acessar o Desempenho do Sistema digitando perfmon no prompt de comando, ou então selecionando o Desempenho do Sistema (ou o Monitor de Desempenho e Confiança, no Windows Vista® e no Windows Server® 2008) no menu Ferramentas Administrativas. Para adicionar contadores de desempenho e objetos a serem monitorados, basta clicar no sinal de adição e selecionar uma entre as diversas opções disponíveis.
Então, como avaliar o funcionamento de um servidor? Há mais de 60 objetos básicos de desempenho, e cada um deles contém vários contadores. Neste artigo, abordarei os contadores que revelam os sinais vitais de um servidor e descreverei os intervalos típicos de amostragem normalmente utilizados pelos engenheiros do Suporte aos Serviços Microsoft® para solucionar problemas relacionados ao desempenho.Logicamente, uma linha de base representa um ponto de referência essencial para a solução de problemas. Como a carga do servidor depende dos requisitos comerciais e também varia de tempos em tempos, dependendo do ciclo de negócios, é importante estabelecer uma linha de base, determinada pela carga de trabalho normal em um período especificado. Isso permite observar alterações e identificar tendências.

 

Como tornar os resultados mais legíveis
 
Antes de me aprofundar na análise dos contadores que representam os sinais vitais dos servidores, explicarei dois truques que facilitam a medição desses sinais vitais usando o Desempenho do Sistema. Observe que esses truques não são necessários no Windows Vista e no Windows Server 2008. Mas, se você estiver executando o Desempenho do Sistema em versões anteriores do Windows, eles poderão ser muito úteis.
Primeiro, você pode remover todos os ruídos produzidos por exemplos irrelevantes que obscurecem a exibição gráfica das linhas de tendência. No Windows Vista e no Windows Server 2008, o Desempenho do Sistema pode exibir até 1.000 pontos de dados na visualização gráfica. Nas versões anteriores do Windows, o limite era de apenas 100 pontos de dados. Quando há mais de 100 pontos, o Desempenho do Sistema classifica os pontos de dados. Uma classificação é representada por uma linha vertical indicando os valores mínimo, médio e máximo dos pontos de exemplo incluídos.
Como você pode ver no gráfico da Figura 1, é difícil identificar a linha de tendência quando há tantos dados exibidos ao mesmo tempo. O gráfico da Figura 2 mostra como é bem mais fácil compreender rapidamente os dados quando todas as informações visuais irrelevantes são desativadas. Para obter mais detalhes sobre como desativar essas linhas verticais, consulte o artigo da Base de Dados de Conhecimento disponível em support.microsoft.com/kb/283110.
 
Figura 1. Dados de desempenho mostrados com classificações irrelevantes e sem vírgulas
 
 
Figura 2. Uma exibição mais clara dos dados, separados por vírgulas
 
O segundo truque consiste em adicionar a separação por vírgulas aos números, tornando muito mais fácil ler os valores mostrados nos contadores. O Windows Vista e o Windows Server 2008 têm a separação por vírgulas habilitada por padrão. Contudo, nas versões anteriores do Windows, o Desempenho do Sistema não habilita as vírgulas por padrão.
Talvez não pareça que isso fará uma grande diferença, mas observe a Figura 1, que mostra os contadores de desempenho sem vírgulas, e depois a Figura 2, que mostra os contadores com vírgulas. Considero a segunda versão muito mais legível. Para obter instruções mais simples sobre como adicionar a separação por vírgulas aos seus contadores de desempenho no Windows XP, consulte o artigo da Base de Dados de Conhecimento em support.microsoft.com/kb/300884.

 

O que e quando medir Os afunilamentos ocorrem quando um recurso alcança o limite da sua capacidade, reduzindo o desempenho de todo o sistema. Os afunilamentos geralmente são causados por recursos insuficientes ou mal configurados, componentes com funcionamento incorreto e solicitações incorretas de recursos por parte de um programa.
Há cinco áreas principais de recursos que podem causar afunilamentos e afetar o desempenho do servidor: disco físico, memória, processo, CPU e rede. Se qualquer um desses recursos for utilizado em excesso, o servidor ou o aplicativo poderá ficar muito lento ou até falhar. Examinarei cada uma dessas cinco áreas, fornecendo diretrizes sobre os contadores que você deve usar e oferecendo sugestões de limites para avaliar o desempenho dos seus servidores.
Como o intervalo de amostragem tem um impacto considerável sobre o tamanho do arquivo de log e a carga do servidor, você deve defini-lo com base na média de tempo decorrido até a ocorrência do problema, de forma a estabelecer uma linha de base antes que ele ocorra novamente. Isso permitirá identificar qualquer tendência que conduza ao problema.
Quinze minutos serão uma boa janela para estabelecer uma linha de base durante as operações normais. Defina um intervalo de amostragem de 15 segundos se a média de tempo decorrido até a ocorrência do problema for de cerca de quatro horas. Se o tempo até a ocorrência do problema for de oito horas ou mais, defina um intervalo de amostragem de pelo menos cinco minutos. Caso contrário, você terá um arquivo de log grande demais, dificultando a análise dos dados.

 

Afunilamento de disco rígido
 
Como o sistema de disco armazena e manipula os programas e os dados no servidor, um afunilamento que afete o uso e a velocidade do disco terá um grande impacto sobre o desempenho geral do servidor.
Observe que, se os objetos de disco não tiverem sido habilitados no seu servidor, você precisará usar a ferramenta de linha de comando Diskperf para habilitá-los. Observe também que % Tempo de Disco pode exceder os 100% e, por isso, eu prefiro usar % Tempo Ocioso, Média de Disco s/Leitura e Média de Disco s/Gravação para obter uma visão mais precisa do nível de ocupação do disco rígido. Você encontra mais informações sobre % Tempo de Disco no artigo da Base de Dados de Conhecimento disponível em support.microsoft.com/kb/310067.
A seguir, estão os contadores que os engenheiros do Suporte aos Serviços Microsoft utilizam para o monitoramento de disco.
LogicalDisk\% Espaço Livre : Mede a porcentagem de espaço livre na unidade lógica de disco selecionada. Fique atento se cair abaixo de 15%, pois você corre o risco de ficar sem espaço livre para o armazenamento de arquivos críticos pelo sistema operacional. Uma solução óbvia para esse problema é acrescentar mais espaço em disco.
PhysicalDisk\% Tempo Ocioso: Mede a porcentagem de tempo de inatividade do disco durante o intervalo de amostragem. A queda do contador abaixo de 20% significa que o sistema de disco está saturado. Avalie a possibilidade de substituir o sistema de disco atual por um mais rápido.
PhysicalDisk\Média de Disco s/Leitura: Mede o tempo médio, em segundos, para a leitura de dados no disco. Um número maior do que 25 ms (milissegundos) significa que o sistema de disco está apresentando latência na leitura do disco. Em servidores de missão crítica que hospedam o SQL Server® e o Exchange Server, o limite aceitável é muito menor, de cerca de 10 ms. A solução mais lógica é substituir o sistema de disco atual por um mais rápido.
PhysicalDisk\Média de Disco s/Gravação: Mede o tempo médio, em segundos, para a gravação de dados no disco. Um número maior do que 25 ms significa que o sistema de disco está apresentando latência ao gravar no disco. Em servidores de missão crítica que hospedam o SQL Server e o Exchange Server, o limite aceitável é muito menor, de cerca de 10 ms. Provavelmente, a solução é substituir o sistema de disco por um mais rápido.
PhysicalDisk\Comprimento Médio da Fila de Disco: Indica quantas operações de E/S aguardam a disponibilidade do disco rígido. Um valor maior do que o número de eixos mais dois significa que o afunilamento pode ser o disco propriamente dito.
Memória\Bytes de Cache: Indica a quantidade de memória usada pelo cache do sistema de arquivos. Pode haver um afunilamento de disco se o valor for superior a 200 MB.

 

Afunilamento de memória
 
A insuficiência de memória geralmente se deve à RAM insuficiente, a um vazamento de memória ou a uma chave de memória colocada dentro de boot.ini. Antes de analisar os contadores de memória, abordarei a chave /3GB.
A presença de mais memória reduz a atividade de E/S do disco e, conseqüentemente, melhora o desempenho dos aplicativos. A chave /3GB foi introduzida no Windows NT® como uma maneira de fornecer mais memória aos programas de modo de usuário.
O Windows usa um espaço de endereço virtual de 4 GB (independentemente da quantidade de RAM física presente no sistema). Por padrão, os 2 GB inferiores são reservados para os programas de modo de usuário e os 2 GB superiores, para os programas de modo kernel. Com a chave /3GB, 3GB são fornecidos aos processos de modo de usuário. Logicamente, isso causa impacto sobre a memória do kernel, que terá apenas 1 GB de espaço de endereço virtual. Isso pode causar problemas, pois os Bytes de Pool Não-Paginável, os Bytes de Pool Paginável, as Entradas Livres de Tabela de Paginação do Sistema e o heap de área de trabalho ficam “apertados” nesse espaço de 1 GB. Assim, a chave /3GB somente deve ser usada após testes detalhados do seu ambiente.
Isso deve ser levado em conta se você suspeitar que está experimentando um afunilamento relacionado à memória. Se a chave /3GB não for a causa dos problemas, você poderá usar os contadores a seguir para diagnosticar um possível afunilamento de memória.
Memória\% Bytes Confirmados em Uso: Mede a taxa de Bytes Confirmados em relação ao Limite de Confirmação — em outras palavras, a quantidade de memória virtual em uso. Um número maior do que 80% indica memória insuficiente. A solução óbvia é o acréscimo de mais memória.
Memória\% Mbytes Disponíveis: Mede a quantidade de memória física, em megabytes, disponível para executar processos. Um valor menor do que 5% do total de RAM física significa que a memória é insuficiente, e isso pode aumentar a atividade de paginação. Para resolver esse problema, basta adicionar mais memória.
Memória\Entradas Livres de Tabela de Paginação do Sistema: Indica o número de entradas de tabela de paginação que não estão atualmente em uso pelo sistema. Se o número for menor do que 5.000, pode haver um vazamento de memória.
Memória\Bytes de Pool Não-Paginável: Mede o tamanho, em bytes, do pool não-paginável. Essa é uma área da memória do sistema para objetos que não podem ser gravados em disco, mas que devem permanecer na memória física enquanto estiverem alocados. Se o valor for maior do que 175 MB (ou 100 MB, com a chave /3GB), pode haver um vazamento de memória. Uma típica Identificação do Evento 2019 é registrada no log de eventos do sistema.
Memória\Bytes de Pool Paginável: Mede o tamanho, em bytes, do pool paginável. Essa é uma área da memória do sistema usada para objetos que podem ser gravados em disco quando não estão em uso. Se o valor for maior do que 250 MB (ou 170 MB, com a chave /3GB), pode haver um vazamento de memória. Uma típica Identificação do Evento 2020 é registrada no log de eventos do sistema.
Memória\Páginas por Segundo: Mede a taxa na qual as páginas são lidas ou gravadas em disco para resolver falhas de páginas de hardware. Se o valor for maior do que 1.000, como resultado da paginação excessiva, pode haver um vazamento de memória.

 

Afunilamento de processador
 
A sobrecarga do processador pode se dever à potência insuficiente do próprio processador, ou então a um aplicativo ineficiente. Você precisa verificar se o processador gasta muito tempo com a paginação, devido à memória física insuficiente. Ao investigar um possível afunilamento de processador, os engenheiros do Suporte aos Serviços Microsoft utilizam os contadores a seguir.
Processador\% Tempo do Processador: Mede a porcentagem do tempo decorrido gasto pelo processador na execução de um thread ocupado. Se a porcentagem for superior a 85%, o processador está sobrecarregado, e pode ser que o servidor precise de um processador mais rápido.
Processador\% Tempo de Usuário: Mede a porcentagem do tempo decorrido gasto pelo processador no modo de usuário. Se o valor for elevado, o servidor está ocupado com o aplicativo. Uma possível solução é otimizar o aplicativo que está utilizando os recursos do processador.
Processador\% Tempo de Interrupção: Mede o tempo que o processador gasta para receber e fazer a manutenção de interrupções de hardware durante intervalos de amostragem específicos. Se o valor for maior do que 15%, o contador indica um possível problema de hardware.
Sistema\Comprimento da Fila de Processador: Indica o número de threads na fila do processador. Se o valor for superior a duas vezes o número de CPUs por um período extenso, isso indica que o servidor não conta com capacidade de processamento suficiente.

 

Afunilamento de rede
 
Logicamente, um afunilamento de rede afeta a capacidade do servidor de enviar e receber dados via rede. Pode ser um problema na placa de rede do servidor, ou talvez a rede esteja saturada e precise ser segmentada. Você pode usar os contadores a seguir para diagnosticar possíveis afunilamentos de rede.
Interface de Rede\Total de Bytes/s:  Mede a taxa pela qual bytes são enviados e recebidos por cada adaptador de rede, inclusive caracteres de enquadramento. Se você descobrir que mais de 70% da interface é consumida, isso significa que a rede está saturada. Para uma placa de interface de rede de 100 Mbps, a interface consumida é de 8,7 MB/s (100 Mbps = 100.000 kbps = 12,5 MB/s* 70%). Em uma situação assim, talvez você queira adicionar uma placa de rede mais rápida ou segmentar a rede.
Interface de Rede\Comprimento da Fila de Saída: Mede, em pacotes, o comprimento da fila de saída de pacotes. Existe saturação da rede se o valor for superior a 2. Você pode solucionar esse problema acrescentando uma placa de rede mais rápida ou segmentando a rede.

 

Afunilamento de processo
 
O desempenho do servidor será afetado consideravelmente se você tiver um processo de comportamento inadequado ou processos não-otimizados. Vazamentos de threads e identificadores causarão, em algum momento, a interrupção do funcionamento do servidor, e o uso excessivo do processador levará ao rastreamento do servidor. Os contadores a seguir são indispensáveis para diagnosticar afunilamentos relacionados a processos.
Processo\Número de Identificadores: Mede o número total de identificadores abertos por um processo no momento. Se o valor for maior do que 10.000, o contador indica um possível vazamento de identificadores.
Processo\Contagem de Threads: Mede o número total de threads ativos em um processo no momento. Pode haver um vazamento de threads se esse número for superior a 500, entre os números mínimo e máximo de threads.
Processo\Bytes Particulares: Indica a quantidade de memória que o processo alocou e que não pode ser compartilhada com outros processos. Pode haver um vazamento de memória se o valor for superior a 250, entre os números mínimo e máximo de threads.
Fonte: Technet Magazine
Espero ter clareado a mente
[ ]’s