Tenho usado DBCC Traceon (3502, 3504, 3605, -1) porque foi recomendado em um blog para descobrir problemas de desempenho relacionados a E/S. Estou executando o MS SQL Server 2008 R2 SP1
Os resultados no meu arquivo SQL Log são mais ou menos assim (números um pouco falsificados):
prestes a registrar o fim do ponto de verificação
último alvo pendente 2, avgWriteLatency 40ms
Taxa de transferência média: 0,67 MB/s, Saturação de E/S: 79, Chaves de contexto 201
FlushCache: limpou 125 Bufs com 69 gravações, em 1447ms (evitou 0 novos bufs sujos)
Ckpt dbid 9 fase 1 finalizada (8)
prestes a registrar o início do ponto de verificação.
Eu realmente não sei como ler isso, ou dividi-lo de uma maneira que eu consiga obter algo realmente significativo com isso.
O que significa "última meta pendente?"
A latência média de gravação significa o tempo de sobrecarga necessário por gravação? ou o tempo entre as gravações? 40 ms parece alto, a unidade física é de 1 TB e está configurada para RAID5.
O que é saturação de E/S?
O que isso tem a ver com os interruptores de contexto. Estou assumindo que as opções de contexto têm algo a ver com multitarefa. Alterando entre trabalhos/gravações.
FlushCache. Eu percebo que isso tem a ver com a limpeza do cache. O que são os Bufs? Essas páginas de dados precisavam ser escritas? Quais são os Bufs sujos? Por que eles seriam evitados?
Uma análise detalhada seria apreciada.
Os sinalizadores de rastreamento que você ativou informarão o que um ponto de verificação está fazendo nos bastidores.
Consulte a postagem no blog de Paul Randall para obter mais detalhes sobre o que foi dito acima. Além disso, o ajuste fino para desempenho ideal tem uma excelente informação - especialmente na seção Em busca de picos .
Algumas leituras realmente internas:
Em vez de se concentrar diretamente no comportamento do ponto de verificação, sugiro que você olhe para DMVs e Perfmon (relacionado ao disco) -
Você pode consultar Investigando gargalos de E/S
Minha resposta:
Bufs, são páginas SQL, são páginas de 8 KB, 8 páginas por existente (um grupo de páginas) que é de 64 KB e é o menor bloco em um arquivo de banco de dados SQL (mas não no arquivo de log, o arquivo de log pode usar os discos físicos menor tamanho de bloco, geralmente 512 Bytes)
Portanto, no meu próprio exemplo, os 125 Bufs eram 125 páginas, quase 1 MB de dados distribuídos em 69 gravações. Demorou um total de 1447 para escrever essas 125 páginas (basicamente 1447 segundos para escrever 125x8KB) e se você multiplicar o tempo que levou pelo Throughput, obterá o tamanho dos dados que foram gravados e é muito próximo dos 125.
Os Dirty Bufs são apenas páginas sujas, que são páginas que foram alteradas, mas não tiveram essas alterações refletidas em nenhum outro lugar, exceto no Cache.
Ainda não entendo a saturação de E/S.
A média de latência de gravação é o tempo necessário para concluir o ponto de verificação (1447) dividido pelo número de gravações. Neste caso, deve ser 20,97 ms. Portanto, os números que usei para o exemplo estão incorretos; Eles não são da mesma entrada de log.
Parece que este servidor está executando lentamente com base nas estatísticas.