Share via

DBCC DROPCLEANBUFFERS

No artigo anterior, comentei sobre a vantagem de usar o SET STATISTICS IO como ferramenta de análise de performance.

Terminei o artigo o mistério: por que o número de read-ahead e logical reads não bate?

image

O resultado esperado deveria ser:

image

 

Limpando o Buffer Bool

O comando DBCC DROPCLEANBUFFERS remove as páginas do banco de dados do cache. Entretanto, o próprio nome já diz: ele remove somente as páginas limpas e que são seguras para serem descartadas. As páginas que possuem modificação são chamadas de suja e não podem ser descartadas enquanto não forem gravadas em disco. Essa explicação está na referência do comando.

DBCC DROPCLEANBUFFERS
https://msdn.microsoft.com/en-us/library/ms187762.aspx

Podemos confirmar esse comportamento através das DMV sys.dm_os_buffer_descriptors:

image

Esse comportamento muda após rodar o CHECKPOINT manualmente:

image

Depois rodar novamente o DBCC DROPCLEANBUFFERS.

image

 

Resultado

O resultdo final foi que o número de logical reads (1257) é igual a read-ahead pages (1257).

image

Um fato interessante é que o tempo aumentou de 369ms para 852ms.

Parece que o banco de dados está ficando mais lento.

 

Sempre é possível piorar!

Vamos desligar as operações de Read-Ahead no servidor inteiro usando o Trace Flag Global 652.

image

Em seguida, limpamos o cache de dados e rodamos novamente a query.

image

Enquanto no artigo anterior a query rodava em 1ms, parece que batemos nosso recorde e chegamos a 1485ms.

 

Conclusão

Limpando o cache e desligando o comportamento de read-ahead afetou o desempenho da query sem mudar nenhum código. Aproveito para avisar de alguns cuidados:

  • Não use DBCC DROPCLEANBUFFERS em produção.
  • Evite consultar a view sys.dm_os_buffer_descriptors
  • Jamais ligue o Trace Flag 652 em produção

No próximo artigo, vamos explorar melhor o mecanismo de read-ahead e tentar uma forma de piorar (?) o desempenho de forma mais acentuada.

Comments

  • Anonymous
    April 20, 2016
    Excelente artigo Catae, aliás, como sempre!no entanto surgiu uma duvida:O traceflag 652 então desabilita a oportunidade das páginas aguardarem para ser comitadas, e são limpas de qqer forma, é isso?obs: vi sua observação de não ativar em prod. abs.Kleber.
    • Anonymous
      April 26, 2016
      Oi Kleber! O trace flag 652 desliga o Read-Ahead (Page Prefetch) e está documentado nesse artigo:https://support.microsoft.com/en-us/kb/920093O objetivo de desligar o Read-Ahead é deixar o impacto do disco mais evidente.Abraços, Fabricio