Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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