Commandes SQL Server pour effacer les caches avant d'exécuter une comparaison de performances
Lorsque vous comparez le temps d'exécution de deux requêtes différentes, il est important de vider le cache pour vous assurer que l'exécution de la première requête ne modifie pas les performances de la seconde.
Dans une recherche Google, j'ai pu trouver ces commandes:
DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
En fait, mes requêtes prennent plus de temps à se réaliser après plusieurs exécutions qu'auparavant. Cependant, je ne suis pas sûr que ce soit la technique recommandée.
Quelle est la meilleure pratique?
Personnellement, pour une requête courante, la 2e exécution et les suivantes ont plus d'importance.
Testez-vous le disque IO ou les performances des requêtes?
En supposant que votre requête s'exécute souvent et est critique, vous souhaitez mesurer cela dans des conditions réelles. Et vous ne voulez pas effacer les caches de serveur de prod à chaque fois ...
Si vous voulez vous pouvez:
DBCC DROPCLEANBUFFERSefface les pages propres (non modifiées) du pool de tampons
Faites précéder cela d'unCHECKPOINTpour vider d'abord toutes les pages sales sur le disqueDBCC FLUSHPROCINDBefface les plans d'exécution de cette base de données
Voir aussi (sur DBA.SE)
Réponse tardive mais peut être utile à d'autres lecteurs
DBCC DROPCLEANBUFFERS Est une commande souvent utilisée pour tester les requêtes et mesurer la vitesse d'exécution des requêtes. Cette commande (lorsqu'elle est exécutée) ne laisse que les pages sales, qui sont en fait une petite partie des données. Il supprime toutes les pages propres d'un serveur entier.
Sachez que cette commande ne doit pas être exécutée sur l'environnement de production. L'exécution de cette commande entraînera un cache de tampon généralement vide. L'exécution de toute requête après avoir exécuté la commande DBCC DROPCLEANBUFFERS, Utilisera des lectures physiques pour ramener les données dans le cache, ce qui sera très probablement beaucoup plus lent que la mémoire.
Encore une fois, traitez cette commande de la même manière que DBCC FREEPROCCACHE - elle ne doit pas être exécutée sur un serveur de production, sauf si vous savez absolument ce que vous faites.
Cela peut être un outil de développement utile car vous pouvez exécuter une requête dans un environnement de test de performance à plusieurs reprises sans aucun changement de vitesse/efficacité en raison de la mise en cache des données en mémoire.
En savoir plus sur: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/
On m'a toujours dit d'utiliser:
dbcc dropcleanbuffers;
De MSDN :
Utilisez DBCC DROPCLEANBUFFERS pour tester les requêtes avec un cache de tampon froid sans arrêter et redémarrer le serveur.
Pour supprimer des tampons propres du pool de tampons, utilisez d'abord CHECKPOINT pour produire un cache de tampons froids. Cela force toutes les pages sales de la base de données actuelle à être écrites sur le disque et nettoie les tampons. Après cela, vous pouvez exécuter la commande DBCC DROPCLEANBUFFERS pour supprimer tous les tampons du pool de tampons.
Les autres réponses sont correctes quant aux raisons de pas exécuter DBCC FREEPROCCACHE. Cependant, il y a aussi deux raisons pour le faire:
- Cohérence
Si vous souhaitez comparer deux requêtes ou procédures différentes qui tentent de faire la même chose de différentes manières, elles risquent de frapper les mêmes pages. Si vous exécutez naïvement la requête n ° 1 puis la requête n ° 2, la seconde peut être beaucoup plus rapide simplement parce que ces pages ont été mises en cache par la première requête. Si vous videz le cache avant chaque exécution, ils démarrent sur un pied d'égalité.
Si vous souhaitez tester les performances du cache à chaud, assurez-vous d'exécuter les requêtes plusieurs fois, en alternant et de supprimer les deux premières exécutions. Faites la moyenne des résultats.
- Pire performance
Supposons que vous ayez une requête qui prend une seconde contre un cache chaud mais une minute contre un cache froid. Une optimisation qui rend la requête en mémoire 20% plus lente mais la requête liée aux entrées-sorties 20% plus rapide pourrait être une grande victoire: pendant les opérations normales, personne ne remarquera les 200 ms supplémentaires dans des circonstances normales, mais si quelque chose force une requête à exécuter sur le disque, prendre 48 secondes au lieu de 60 peut sauver une vente.
C'est moins une préoccupation sur les systèmes modernes avec des dizaines de gigaoctets de mémoire et relativement rapide SAN et stockage SSD, mais cela compte toujours. Si un analyste exécute une requête de balayage de table massive contre votre = OLTP base de données qui efface la moitié de votre cache de tampon, les requêtes efficaces en termes de stockage vous permettront de vous remettre à niveau plus rapidement.