Share via

Os 7 Grandes Mitos do Perfmon (Parte 3)

  • Article

No primeiro post da série Os 7 Grandes Mitos do Perfmon (Parte 1), comentei sobre os contadores:

  • Buffer Manager:Buffer Cache Hit Ratio
  • LogicalDisk: Average Disk Queue Length e LogicalDisk: %Disk Busy

Depois abordei os contadores relacionados ao Paging File (Parte 2):

  • Paging File:%Usage
  • Memory: Page Faults/sec e Memory: Pages/sec

Agora vamos terminar com os 3 últimos contadores.

 

5. SQL Access Methods: Page Splits/sec

O contador Page Splits/sec indica o número de ocorrências de page splits no servidor.

Os registros são armazenados em páginas de 8Kb no servidor. Quando o processo de inserção de registro tenta inserir novos dados, mas não encontra espaço livre na página, então inicia-se o processo de page split. Nesse processo, metade dos registros são movidos para uma nova página, liberando espaço da página original. Após o processo de page split, as páginas envolvidas ficam com 50% de espaço livre e podem continuar o processo de inserção.

Normalmente esse é o contador favorito para iniciar uma conversa sobre “Fill factor”, pois altos números do contador Page splits/sec indicam que as páginas estão frequentemente cheias. Entretanto, o processo de Page Split ocorre naturalmente durante a inserção de dados e não corresponde necessariamente a um problema. Processos de inserção em massa causam sempre um alto número de page splits/sec.

Se realmente for necessário investigar a ocorrência de Page Splits, recomendo que utilize a DMV sys.dm_db_index_operational_stats.

Entretanto, a principal análise é validar os resultados de fragmentação usando a DMF sys.dm_db_index_physical_stats (versão moderna do DBCC SHOWCONTIG).

 

6. SQL Locks: Lock Waits/sec

O contador de Lock Waits/sec indica quantas sessões entram em bloqueios por segundo. Usar o Perfmon para monitorar os locks é algo que acho interessante na teoria.

Exemplo: Estou no trânsito de São Paulo e de repente começou a chover. Quero monitorar quantas vezes fico bloqueado por algum semáforo usando um contador semelhante ao Lock Waits/sec.

Na prática, isso tem resultados curiosos:

A chuva piorou bastante e não estou andando e ainda não consegui atravessar a avenida. Por isso, o contador Lock Waits/sec indica 0, porque não estou passando por mais nenhum outro semáforo.

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)”.

 

7. SQL General Statistics: User Connections

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.

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.

Muito semelhante ao User Connections, são os contadores chamados “SQL Statistics: Batch Requests/sec” e “SQLStatistics: SQL Compilations/sec”. O processo de compilação e execução depende muito do tipo de comando submetido. Existem comandos ad-hoc que podem ser facilmente compilados e executados. Por outro lado, existem comandos que acabam com o desempenho da máquina.

Como disse no artigo Perfmon: Falso sentido de monitoração, use o Performance Monitor para criar baselines de comparação do servidor. Houve aumento do número de conexões, batches/seg, números de compilações? Se você quiser saber a verdadeira causa, então abandone (temporariamente) o Perfmon e use a estratégia correta (DMV ou XE).

 

Finalmente terminamos com a lista dos 7 Grandes Mitos do Performance Monitor.

 

No próximo artigo, farei a seleção dos contadores do Perfmon que você DEVE usar.

Comments

  • Anonymous
    February 01, 2016
    The comment has been removed