Eu tive sp_BlizFirst rodando por alguns dias a cada 12 minutos para capturar as várias estatísticas.
O que eu percebi, porém, é que ele não parece reunir muitas estatísticas de desempenho relacionadas a arquivos além das paradas de E/S.
Há informações suficientes para tomar uma decisão sobre se a E/S é um problema ou não com base nas Estatísticas de espera e paradas de E/S? Não consigo encontrar nas tabelas Blitz nenhuma menção ao Disk avg. tempo de leitura, disco avg. tempo de gravação, méd. comprimento da fila de disco que eu pensei que deveria ser considerado também?
Alguém pode dar algum feedback sobre o abaixo? Minhas estatísticas de paralelismo definitivamente precisam ser analisadas adequadamente (CXPACKET), mas também estou curioso sobre o desempenho de minha entrada/saída de disco. As esperas do OLDEDB, acredito, estão sendo causadas por servidores vinculados e Idera SQL Diagnostic Manager monitorando a instância a cada 1 minuto.
De https://www.sqlskills.com/blogs/paul/are-io-latencies-killing-your-performance/ eu li o seguinte: Todo mundo tem sua ideia do que constitui latência de E/S boa ou ruim, e aqui está minha take: Excelente: < 1ms Muito bom: < 5ms Bom: 5 – 10ms Ruim: 10 – 20ms Ruim: 20 – 100ms Chocantemente ruim: 100 – 500ms UAU!: > 500ms
Se eu for por isso, estou na categoria Ruim.
Aqui estão minhas estatísticas de espera:
Servidor1
A parada de E/S de leitura média é 23,91
O MAX Read I/O Stall era 1162
A parada média de E/S de gravação é de 0,71
O MAX Write I/O Stall era 139
e aqui está o extrato completo.
Servidor 2
A parada de E/S de leitura média é 26,28
O MAX Read I/O Stall foi de 428
A parada média de E/S de gravação é de 2,60
O MAX Write I/O Stall era 667
Isenção de responsabilidade: sou um dos autores do sp_BlitzFirst e do First Responder Kit.
A seção de estatísticas de espera está no topo por um motivo: você precisa se concentrar em seus principais tipos de espera. Não importa o quão rápido ou lento são suas unidades se o SQL Server não estiver esperando por elas. Ótimo exemplo: digamos que você tenha um banco de dados somente leitura hospedado em um servidor com memória suficiente para armazenar em cache todo o banco de dados e nenhuma de suas consultas atingiu o TempDB. Uma vez que os dados estão no cache, importa quão lentos são seus discos? Kinda - para tarefas de manutenção como backups e reconstruções de índice - mas não para consultas de usuários finais.
Agora, veja as 3 principais esperas do seu servidor:
Ei, cara - sua espera superior está chegando DEZ VEZES MAIOR do que sua espera de armazenamento.
Esqueça o armazenamento: você está latindo na árvore errada. Concentre-se no seu tipo de espera superior. Para ajustar o paralelismo, acesse https://BrentOzar.com/go/cxpacket . A história curta: