it-swarm.it

Comandi di SQL Server per cancellare le cache prima di eseguire un confronto delle prestazioni

Quando si confrontano i tempi di esecuzione di due query diverse, è importante svuotare la cache per assicurarsi che l'esecuzione della prima query non modifichi le prestazioni della seconda.

In una ricerca Google, ho potuto trovare questi comandi:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

In effetti, le mie domande stanno richiedendo un tempo più realistico per essere completato dopo diverse esecuzioni rispetto a prima. Tuttavia, non sono sicuro che questa sia la tecnica consigliata.

Qual è la migliore pratica?

49
andrerpena

Personalmente, per una query comune la seconda e le successive esecuzioni contano di più.

Stai testando il disco IO o le prestazioni della query?

Supponendo che la query venga eseguita spesso ed è fondamentale, quindi si desidera misurarla in condizioni di vita reali. E non vuoi cancellare le cache del server prod ogni volta ...

Se vuoi, puoi:

  • DBCC DROPCLEANBUFFERS cancella le pagine pulite (non modificate) dal pool di buffer
    Precede quello con un CHECKPOINT per scaricare prima tutte le pagine sporche sul disco
  • DBCC FLUSHPROCINDB cancella i piani di esecuzione per quel database

Vedi anche (su DBA.SE)

45
gbn

Risposta in ritardo ma può essere utile per altri lettori

DBCC DROPCLEANBUFFERS è un comando spesso utilizzato per il test delle query e per misurare la velocità di esecuzione delle query. Questo comando (quando eseguito) lascia solo le pagine sporche, che in realtà è una piccola porzione di dati. Rimuove tutte le pagine pulite per un intero server.

Si noti che questo comando non dovrebbe non essere eseguito nell'ambiente di produzione. L'esecuzione di questo comando comporterà cache buffer per lo più vuota. Esecuzione di qualsiasi query dopo aver eseguito il DBCC DROPCLEANBUFFERS, utilizzerà le letture fisiche per riportare i dati nella cache, che molto probabilmente sarà molto più lento della memoria.

Ancora una volta, tratta questo comando in modo simile a DBCC FREEPROCCACHE - non dovrebbe essere eseguito su alcun server di produzione a meno che tu non sappia assolutamente cosa stai facendo.

Questo può essere un utile strumento di sviluppo perché è possibile eseguire ripetutamente una query in un ambiente di test delle prestazioni senza alcuna variazione di velocità/efficienza a causa della memorizzazione nella cache dei dati in memoria.

Ulteriori informazioni su: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

15
Thomas Bovee

Mi è sempre stato detto di usare:

dbcc dropcleanbuffers;

Da MSDN :

Utilizzare DBCC DROPCLEANBUFFERS per testare le query con una cache buffer fredda senza arrestare e riavviare il server.

Per eliminare i buffer puliti dal pool di buffer, utilizzare innanzitutto CHECKPOINT per produrre una cache buffer fredda. Ciò impone che tutte le pagine sporche per il database corrente vengano scritte su disco e pulisce i buffer. Dopo aver effettuato l'operazione, è possibile emettere il comando DBCC DROPCLEANBUFFERS per rimuovere tutti i buffer dal pool di buffer.

10
DaveShaw

Le altre risposte sono corrette sui motivi per non eseguire DBCC FREEPROCCACHE. Tuttavia, ci sono anche un paio di ragioni per farlo:

  1. Consistenza

Se si desidera confrontare due diverse query o procedure che stanno tentando di fare la stessa cosa in modi diversi, è probabile che colpiscano le stesse pagine. Se si esegue in modo ingenuo la query n. 1, quindi la query n. 2, la seconda potrebbe essere molto più veloce semplicemente perché quelle pagine sono state memorizzate nella cache dalla prima query. Se si svuota la cache prima di ogni esecuzione, iniziano su un piano uniforme.

Se si desidera testare le prestazioni della hot cache, assicurarsi di eseguire le query più volte, alternando e scartare le prime due esecuzioni. Media dei risultati.

  1. Peggior prestazioni

Supponi di avere una query che richiede un secondo rispetto a una hot cache ma un minuto a una cold cache. Un'ottimizzazione che rende la query in memoria più lenta del 20% ma la query associata a IO il 20% più veloce potrebbe essere una grande vittoria: durante le normali operazioni nessuno noterà i 200 ms in più in circostanze normali, ma se qualcosa costringe una query a eseguito su disco, impiegando 48 secondi anziché 60 potrebbe salvare una vendita.

Ciò è meno preoccupante per i sistemi moderni con decine di gigabyte di memoria e relativamente veloce SAN e archiviazione SSD, ma è comunque importante. Se qualche analista esegue una massiccia query di scansione della tabella contro il tuo = OLTP che cancella metà della cache del buffer, le query efficienti in termini di archiviazione ti consentiranno di tornare rapidamente alla velocità.

3