Exibir código-fonte para Contadores de desempenho

==Introdução==

O objetivo deste documento é oferecer uma visão geral sobre os principais contadores do Perfmon, bem como um direcionamento para as análises de desempenho.

==Contadores==


===Disco===

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Contador'''
| align="center" style="background:#f0f0f0;"|'''Caminho'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
| align="center" style="background:#f0f0f0;"|'''Informações para análise'''
|-
|Percentagem de espaço livre
|LogicalDisk \ % Free Space
|Mostra a porcentagem do espaço total utilizável no disco lógico selecionado.
|
|-
|Comprimento da Fila de Disco Atual
|LogicalDisk Disk\ Current Disk Queue Length
|Technet:
Esse contador mostra o número de solicitações pendentes no disco no momento em que os dados de desempenho são coletados.

O 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.

----

Technet: Para esse contador, valores menores são melhores. Valores acima de 2 por disco podem indicar um afunilamento e devem ser investigados. Isso significa que um valor até 8 pode ser aceitável para um LUN composto de quatro discos. Os afunilamentos podem criar uma lista de pendências que pode se expandir para além do servidor atual que está acessando o disco e resultar em longos tempos de espera para os usuários. As possíveis soluções para um afunilamento são adicionar discos à matriz RAID, substituir os discos existentes por discos mais rápidos ou mover alguns dados para outros discos.

----

Fabio Zibiani: 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.
|-
|Comprimento Médio da Fila de Disco
|LogicalDisk Disk\ Average Disk Queue Length
|TechNET: Esse contador mostra o número médio de solicitações de leitura e gravação que estavam enfileiradas para o disco selecionado durante o intervalo de tempo.
|Technet: A regra é que deve haver duas ou menos solicitações de leitura e gravação pendentes por eixo, mas isso pode ser difícil de medir devido à virtualização de armazenamento e a diferenças nos níveis de RAID entre configurações. Verifique se há comprimentos de fila de disco maiores do que a média, combinados a latências de disco maiores do que a média. Essa combinação pode indicar que o cache de matriz de armazenamento está sobrecarregado ou que o compartilhamento de eixos com outros aplicativos está afetando o desempenho.

----

Fabrício Catae: Os contadores de fila de disco e porcentagem de uso do disco são os piores indicadores de Performance. Jamais use. 
Não existe um valor de mínimo ou máximo
As pessoas falam em 2 vezes o número de spindle, sendo que podemos considerar que os spindles são os discos físicos. Entretanto, o mundo atual de SAN e virtualização impede que esse número seja determinado com precisão. Além disso, os discos montados em LUN podem compartilhar os mesmos arrays de disco com outras LUN – fica inviável determinar qual seria esse valor limite.
Esses contadores fornecem muitos falsos-positivos.
Todos os sistemas de alta performance de disco realizam enfileiramento de disco para aumentar o throughput. Por isso, ao invés de monitorar a fila, é mais importante medir o tempo de latência do storage. A fila é consêquência: quando o storage apresenta alta latência de disco, causa enfileiramento das requisições.

O problema desse contador é que ninguém sabe o que isso significa. Se você quiser falar sobre fila com pessoal de storage, então fale sobre “outstanding I/O” e não sobre “Average Disk Queue Length”. Curiosamente, o contador para medir “outstanding I/O” possui um nome muito semelhante: “Current Disk Queue Length”.
|-
|Percentagem de tempo ocioso
|LogicalDisk \ % Idle time
|Este contador fornece quanto tempo o disco permaneceu em estado de repouso, ou seja, todos os pedidos do sistema operacional para o disco ter sido concluída e há zero de pedidos pendentes. Este contador varia de 100 (ou seja, sempre ocioso) para 0 (ou seja, sempre ocupado).

----

Fabio Zibiani:
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.
|Acima de 75%
|-
|}

===Processador===

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Contador'''
| align="center" style="background:#f0f0f0;"|'''Caminho'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
| align="center" style="background:#f0f0f0;"|'''Informações para análise'''
|-
|Tempo total do processador
|Processor \ %Processor time
|Mede a utilização da CPU de cada processador.
|Não exceder 80% por mais de 10 minutos ao longo do período de teste.

Fabrício Catae: Verificar se o consumo de CPU está abaixo de 80%. É importante manter uma margem de 10-20% para permitir um eventual pico de utilização.
|-
|Tempo privilegiado
|Processor \ %Privileged Time
|
|Fabrício Catae: Verificar se o consumo em Kernel Time está abaixo de 30%. Não faz sentido um servidor de banco de dados gastar mais tempo em Kernel executando tarefa de sistemas ao invés de executar as queries SQL.
|-
|Fila do processador
|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. 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.

----

Fabrício Catae: Monitorar esse valor ao longo do tempo e comparar com o consumo de CPU. Alto consumo de CPU associado a filas de processador indicam que existem processos externos afetando o desempenho do SQL Server.
|-
|Mudança de contexto
|System \ Context Switches/sec
|A mudança de contexto ocorre quando o kernel muda o processador de um segmento para outro, por exemplo, quando um segmento com uma prioridade maior do que o segmento em execução torna-se pronto.
|Quanto menor melhor.
O valor ideal recomendado é de no máximo 10000 por CPU.

----

A quantidade de troca de contexto em um SQL Server deve se manter baixa mesmo sob carga. Um aumento no indicador Context Switches/sec ocorre devido a execução de threads de alta prioridade, como as Interrupções (INT), Asynchronous Procedure Call (APC) e Deferred Procedure Call (DPC) ou se houver um grande número de chamadas ao Kernel (System Calls/sec) ou disparo de exceções (Exception Dispatches/sec). O valor ideal recomendado é de no máximo 10000 por CPU.
|-
|}

===Memória===

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Contador'''
| align="center" style="background:#f0f0f0;"|'''Caminho'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
| align="center" style="background:#f0f0f0;"|'''Informações para análise'''
|-
|Páginas/segundo
|Memory \ Pages/sec
|Mede o número de páginas por segundo que são paginadas fora da memória RAM para a memória virtual.

Windows: Pages/sec is the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays.  It is the sum of Memory\\Pages Input/sec and Memory\\Pages Output/sec.  It is counted in numbers of pages, so it can be compared to other counts of pages, such as Memory\\Page Faults/sec, without conversion. It includes pages retrieved to satisfy faults in the file system cache (usually requested by applications) non-cached mapped memory files.
|Se o número for alto indica falhas graves. O limite normalmente é de 20 páginas/s

----

Fabrício Catae: Pages/sec – Conhecido como “hard page faults”, essas paginações são movimentações de dados entre a memória e disco. Esse é um processo muito mais custoso do que o “soft page fault”. A paginação da memória para o Paging File é apenas um dos possíveis causadores de “hard page faults”. Na realidade, qualquer mecanismo de “Memory Mapping” contabiliza como uma operação de movimentação de dados. O problema desse contador é que operações simples como cópia, leitura e gravação de arquivo afetam o “pages/sec”.
Quando há problema de falta de memória, é possível observar um leve aumento nesse contador. Na prática, altos valores de “Memory:Pages/sec” são normalmente gravação do arquivo de Backup ou cópia de arquivo usando o File Explorer.
Partindo do princípio de que o SQL Server não usa Paging File, não recomendo que faça a monitoração de paginação do SO. Entretanto, se você realmente quer diagnosticar algum mecanismo de paginação, então o ideal é monitorar a variação de tamanho do Working Set dos processos.	

----

Microsoft: If the Pages / sec multiplied by 4,000 (the 4k page size) is greater than 70% of the total number of Logical Disk Bytes / sec to the disk(s) where the page file is located on a consistent basis then you should investigate. 
Translation:  If paging to disk is > 70% of your total disk activity on a consistent basis then there may be an issue

----

Sqlshack: The average Pages/sec value should be below 50. It’s not possible to reduce the value to zero, as moving pages from memory and to memory always occurs while the operating system is running. The more memory the server has, fewer pages have to be written and read due to page faults

A high value of Pages/sec indicates intensive memory activity – many pages are written from disk to RAM and read from RAM to disk. High Pages/sec values can indicate insufficient RAM memory, overhead and SQL Server performance degradation, but it doesn’t necessarily have to be so. A high Pages/sec value can also be caused by sequential reading of a file mapped in memory. To determine whether this is the case, check the Memory Available Bytes and Paging File % Usage values.
|-
|% Memória virtual comprometida
|Memory \ %Committed Bytes In Use
|Indica a percentagem da memória comprometida utilizada dentro do limite dado pela soma da memória RAM e Page File.

Este é um contador importante e é útil quando queremos determinar se precisamos instalar mais RAM ou quando queremos saber se o pagefile está configurado corretamente.
|Abaixo de 75% e que não tenha grande variação no indicador.

----

Fabio Zibiani: 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.
|-
|Page faults
|Memory \ Page faults
|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.
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.
|Fabrício Catae: Entretanto, existem motivos mais fortes para evitar esses contadores:

Page Faults/sec – Conhecido também como “soft page faults”, essas paginações ocorrem somente para reposicionar a memória sem a necessidade de ir ao disco. Esse é um processo comum presente em qualquer Sistema Operacional multitasking. A ocorrência de “soft page faults” está mais relacionada a transição de contexto entre processos do que falta de memória.
Portanto, altos valores de Page Faults/sec não correspondem a problemas.

Pages/sec – Conhecido como “hard page faults”, essas paginações são movimentações de dados entre a memória e disco. Esse é um processo muito mais custoso do que o “soft page fault”. A paginação da memória para o Paging File é apenas um dos possíveis causadores de “hard page faults”. Na realidade, qualquer mecanismo de “Memory Mapping” contabiliza como uma operação de movimentação de dados. O problema desse contador é que operações simples como cópia, leitura e gravação de arquivo afetam o “pages/sec”.
Quando há problema de falta de memória, é possível observar um leve aumento nesse contador. Na prática, altos valores de “Memory:Pages/sec” são normalmente gravação do arquivo de Backup ou cópia de arquivo usando o File Explorer. Portanto, altos valores de Page Faults/sec não correspondem necessariamente a problemas.

----

Fabio Zibiani: 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.
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.
|-
|}

===Rede===

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Contador'''
| align="center" style="background:#f0f0f0;"|'''Caminho'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
| align="center" style="background:#f0f0f0;"|'''Informações para análise'''
|-
|Kbytes totais pela interface de rede / Interface de rede total I/O
|Network Interface \ Bytes total / sec
|Indica quantos Kbytes foram enviados e recebidos a cada segundo pela interface de rede.
|Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor).
|-
|Falhas de conexão (TCP)
|TCPv4 \ Connection Failures
|Este é o número bruto de conexões TCP que falharam desde que o servidor foi iniciado. Uma falha normalmente indica uma perda de dados em lugar no processo. A perda pode ocorrer em muitos locais. Esta poderia ser uma indicação de um outro dispositivo que está sendo para baixo, ou problemas com a configuração do lado do cliente do software.

Windows: The TCP performance object consists of counters that measure the rates at which TCP Segments are sent and received by using the TCP protocol.  It includes counters that monitor the number of TCP connections in each TCP connection state.
Connection Failures is the number of times TCP connections have made a direct transition to the CLOSED state from the SYN-SENT state or the SYN-RCVD state, plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state.
|Quanto menor melhor.
|-
|Tempo de vazão
|W3SVC_W3WP / Request / Sec
|Mostra o número de requisições por segundo que seu site está atendendo. Na maioria das aplicações este número é relativamente baixo não passando de 5 ou 10 já que pra que este contador seja incrementado é necessário que as requests sejam executadas exatamente no mesmo segundo. Isto geralmente acontece em duas situações: você tem vários usuários acessando sua aplicação ao mesmo tempo ou caso suas requisições demorem muito pra terminar a execução.

HTTP requests/sec being processed by the worker process.
|O número é relativamente baixo não passando de 5 ou 10.
|-
|}

===SQL===

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Contador'''
| align="center" style="background:#f0f0f0;"|'''Caminho'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
| align="center" style="background:#f0f0f0;"|'''Informações para análise'''
|-
|Expectativa de vida da página
|Buffer Manager \ Page Life Expectancy
|Indica o número em segundos que uma página vai ficar na área de buffers, sem referências.

Page Life Expectancy is just an estimation SQL Server makes on how long it thinks a page will last in a buffer.
|Fabrício Catae: Partindo do princípio de que o SQL Server não usa Paging File, não recomendo que faça a monitoração de paginação do SO. Entretanto, se você realmente quer diagnosticar algum mecanismo de paginação, então o ideal é monitorar a variação de tamanho do Working Set dos processos.

Verificar se esse valor se mantém constante ou subindo ao longo do tempo. O cálculo do Page Life Expectancy é mais complexo em máquinas NUMA e corresponde a uma média harmônica entre os nós. As quedas desse contador indicam o momento de aumento de carga. Valores de referência:

 <10 : excessivamente baixo, podendo gerar erros, asserts e dumps
 <300 : baixo
 1000: razoável
 5000 : bom

----

Um número baixo indica que as páginas estão sendo despejadas sem gastar muito tempo no cache, o que reduz a eficácia do cache. O ideal é que este valor seja sempre superior a 300 segundos. Valores inferiores podem indicar necessidade de memória para a instância SQL Server.

----

The recommended value of the PLE counter is (updated: minimum of) 300 seconds.
|-
|Número de deadlocks por segundo
|SQLServer:Locks \ Number of Deadlocks / sec
|Informa a contagem de quantos deadlocks estão ocorrendo por segundo no sistema.
|Quanto menor melhor.

----

Fabrício Catae: O contador de Lock Waits/sec não fornece muita pistas sobre o desempenho do servidor. No geral, esse contador apresenta um valor flutuante e com pouco significado. Em condições de problemas ou de tranquilidade (situações completamente opostas), ele indica zero.

Os demais contadores da família de Lock são confusos. É praticamente impossível conseguir enxergar Number of Deadlock/sec maior do que 1. Lock timeouts possui um nome atrativo, mas geralmente a query sofre timeout (note que lock timeout está associado a @@LOCK_TIMEOUT).

Recomendo que use as DMV sys.dm_os_waiting_tasks e sys.dm_exec_requests para acompanhar os bloqueios. Entretanto, se realmente for importante monitorar os locks usando o Perfmon, então considere o uso do “Lock Wait Time (ms)” e “Average Wait Time (ms)”.
|-
|Request bloqueados
|Server \ Blocking Requests Rejected
|Informa a quantidade de resquest bloqueados.
|Quanto menor melhor
|-
|User connections
|SQL General Statistics \ User Connections
|Fabrício Catae: O contador de “User connection” diz quantas sessões estão conectadas ao servidor. Na realidade, não há nenhum problema em monitorar esse contador, visto que o servidor possui um limite máximo de 30 mil conexões. O problema ocorre quando as pessoas usam esse contador para medir a carga no servidor.
|Fabrício Catae: Por exemplo, qual dos servidores está mais sobrecarregado? (a diferença é de 50 vezes!)

•	Servidor A com 100 conexões

•	Servidor B com 5000 conexões

Entretanto, a carga depende de quais comandos que estão sendo executados no servidor. Consigo imaginar um usuário chamado DBA, que é capaz de executar um único comando DBCC CHECKDB, e é capaz de causar muito mais carga do que várias aplicações rodando ao mesmo tempo.
|-
|Buffer Manager:Page Reads/sec
|Buffer Manager \ Page Reads/sec
|Fabrício Catae: Para saber quantas requisições (em valor absoluto) estão indo ao disco.
|
|-
|}

===JMeter===

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Contador'''
| align="center" style="background:#f0f0f0;"|'''Caminho'''
| align="center" style="background:#f0f0f0;"|'''Descrição'''
| align="center" style="background:#f0f0f0;"|'''Informações para análise'''
|-
|Vazão
|Relatório agregado
|Informa a quantidade de dados transferidos.
|
|-
|Percentagem de erros
|Relatório agregado
|Indica a porcentagem de erro.
|Quanto menor melhor.
|-
|Samplers
|Relatório agregado
|Quantidade de samplers executados para cada controlador de transação
|
|-
|Tempos de resposta
|Relatório agregado \ 90% line, 95% line, 99% line, Mediana, Mín, Max
|Indica os tempos de resposta.
|Mediana: Significa que 50% dos samplers tiveram tempo menor do que a mediana. Consequentemente, outros 50% foram maiores que a mediana.

90% line: Significa que 90% dos samplers tiveram tempo menor que o tempo exibido. Consequentemente, outros 10% tiveram o tempo maior que o exibido.

95% line: o mesmo que 90% line.

99% line: o mesmo que 90% line.

Min: menor tempo registrado pelos samplers.

Max: maior tempo registrado pelos samplers.
|-
|}