Início / dba / Perguntas / 10818
Accepted
andrerpena
Asked: 2011-11-29 04:32:00 +0800 CST

Comandos do SQL Server para limpar caches antes de executar uma comparação de desempenho

  • 772

Ao comparar o tempo de execução de duas consultas diferentes, é importante limpar o cache para garantir que a execução da primeira consulta não altere o desempenho da segunda.

Em uma pesquisa do Google, encontrei estes comandos:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

Na verdade, minhas consultas estão demorando mais para serem concluídas após várias execuções do que antes. No entanto, não tenho certeza se esta é a técnica recomendada.

Qual é a melhor prática?

sql-server performance

4 respostas

  1. Best Answer

    Pessoalmente, para uma consulta comum, a segunda e as execuções subsequentes são mais importantes.

    Você está testando a E/S de disco ou o desempenho da consulta?

    Supondo que sua consulta seja executada com frequência e seja crítica, você deseja medir isso em condições da vida real. E você não deseja limpar os caches do servidor de produção toda vez ...

    Se você quiser você pode:

    • DBCC DROPCLEANBUFFERSlimpa as páginas limpas (não modificadas) do conjunto de buffers
      Preceda isso com um CHECKPOINTpara liberar todas as páginas sujas no disco primeiro
    • DBCC FLUSHPROCINDBlimpa os planos de execução para esse banco de dados

    Veja também (no DBA.SE)

    • 47

  2. Resposta tardia, mas pode ser útil para outros leitores

    DBCC DROPCLEANBUFFERSé um comando frequentemente usado para teste de consulta e medição da velocidade de execução da consulta. Este comando (quando executado) deixa para trás apenas as páginas sujas, que na verdade são uma pequena porção de dados. Ele remove todas as páginas limpas de um servidor inteiro.

    Esteja ciente de que este comando não deve ser executado em ambiente de produção. A execução desse comando resultará em um cache de buffer praticamente vazio. A execução de qualquer consulta após a execução do DBCC DROPCLEANBUFFERScomando usará leituras físicas para trazer de volta os dados para o cache, o que provavelmente será muito mais lento que a memória.

    Novamente, trate este comando de forma semelhante a DBCC FREEPROCCACHE- ele não deve ser executado em nenhum servidor de produção, a menos que você saiba absolutamente o que está fazendo.

    Essa pode ser uma ferramenta de desenvolvimento útil porque você pode executar uma consulta em um ambiente de teste de desempenho repetidamente sem nenhuma alteração na velocidade/eficiência devido ao armazenamento em cache de dados na memória.

    Saiba mais em: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

    • 15

  3. Sempre me disseram para usar:

    dbcc dropcleanbuffers;

    Do MSDN :

    Use DBCC DROPCLEANBUFFERS para testar consultas com um cache de buffer frio sem desligar e reiniciar o servidor.

    Para eliminar buffers limpos do conjunto de buffers, primeiro use CHECKPOINT para produzir um cache de buffer frio. Isso força todas as páginas sujas do banco de dados atual a serem gravadas no disco e limpa os buffers. Depois de fazer isso, você pode emitir o comando DBCC DROPCLEANBUFFERS para remover todos os buffers do pool de buffers.

    • 11

  4. Edit: a pergunta do OP é sobre caches e o uso de comandos como DBCC FREEPROCCACHE, que limpa os planos de execução armazenados. Aparentemente, eu não estava com meus óculos, porque minha resposta abordou buffers, o que significa dados lidos recentemente armazenados na memória para recuperação rápida. Espero que isso ainda seja útil para alguém.

    As outras respostas estão corretas sobre os motivos para não executar [DBCC DROPCLEANBUFFERS][1]. No entanto, também existem algumas razões para fazê-lo:

    1: Consistência

    Se você quiser comparar duas consultas ou procedimentos diferentes que estão tentando fazer a mesma coisa de maneiras diferentes, é provável que cheguem às mesmas páginas. Se você executar ingenuamente a consulta nº 1 e depois a consulta nº 2, a segunda pode ser muito mais rápida simplesmente porque essas páginas foram armazenadas em cache pela primeira consulta. Se você limpar o cache antes de cada execução, eles começarão em pé de igualdade.

    Se você quiser testar o desempenho do hot-cache, certifique-se de executar as consultas várias vezes, alternando, e descarte as primeiras execuções. Faça a média dos resultados.

    2: Desempenho no pior caso

    Digamos que você tenha uma consulta que leva um segundo em um cache quente, mas um minuto em um cache frio. Uma otimização que torna a consulta na memória 20% mais lenta, mas a consulta vinculada ao IO 20% mais rápida pode ser uma grande vitória: ninguém se importará com os 200 ms extras de tempo de execução em circunstâncias normais, mas se algo forçar uma consulta a executado em disco, levando 48 segundos em vez de 60 é material. Pode ser o suficiente para salvar uma venda.

    Isso é menos preocupante em sistemas modernos com dezenas de gigabytes de memória e armazenamento SAN e SSD relativamente rápido, mas ainda é importante. Se algum analista executar uma consulta de varredura de tabela maciça em seu banco de dados OLTP que elimina metade do cache do buffer, as consultas com eficiência de armazenamento farão com que você volte à velocidade mais cedo.

    • 5

relate perguntas