Estou tentando rastrear o que está causando o aumento de alguns tempos de resposta quando os dados são compactados pela compactação de página, quando o sistema não está vinculado à CPU e 95% das respostas apresentam uma diminuição no tempo de resposta.
Então, o que fiz foi rastreá-lo para um único processo acontecendo no sistema e criei o perfil desse processo para determinar quais SPs e UFNs são disparados durante o processo. Meu pensamento original era que eu poderia executar cada SP e UFN isoladamente e dar uma olhada nos planos de consulta para ver onde as varreduras completas estão acontecendo, isso pode exigir que os dados sejam descompactados da compactação e pode causar uma espera para disparar.
Então o que tenho agora é:
- Uma lista de SPs com os parâmetros usados
- O banco de dados no qual os SPs são executados
- Acesso de administrador irrestrito ao sistema para reproduzir o problema
- Um rastreamento de perfil do processo em questão
Como há algo como 35 SPs/UFNs que eu teria que classificar, estou me perguntando qual é a maneira mais eficiente de restringir a causa. Posso inferir que alguns SPs são culpados mais prováveis do que outros pela minha experiência com o sistema, mas gostaria de tentar reduzi-lo de uma forma mais científica. Existem ferramentas ou metodologias que possam me ajudar a descobrir os infratores mais prováveis?
Se eu puder determinar os objetos que são mais lentos quando compactados do que quando não, isso ajudará a informar nossa estratégia em relação à compactação de página.
Uma abordagem científica é baseada na coleta rotineira de informações de desempenho de processos e procedimentos, seja usando um pacote comercial ou uma solução mais desenvolvida internamente . Você também pode começar do zero coletando informações do Profiler ou Extended Events. O importante é capturar dados regularmente e torná-los facilmente consumíveis (por exemplo, usando
SSRS).As informações históricas utilizáveis facilitam o rastreamento de mudanças graduais de desempenho ao longo do tempo, antecipam maiores requisitos de recursos antes que ocorram, diagnosticam mudanças repentinas e identificam e testam áreas para melhoria.
Nesse último ponto, acredito que sua abordagem deve ser algo como isto:
ROWePAGEcompressão na área alvo de melhoriaIsso é muito mais fácil do que tentar rastrear regressões de desempenho em código complexo após o fato, sem uma linha de base para comparação.
Se você tem certeza de que esses 35 programáveis são os culpados, uma combinação de perfil/eventos para tempo decorrido e planos em cache, além de sys.dm_exec_query_stats , deve ajudá-lo a entender onde está a dor.
O comentário de @Paul sobre o registro de uma linha de base é importante, no entanto.