it-swarm-eu.dev

SQL Server-Befehle zum Löschen von Caches vor dem Ausführen eines Leistungsvergleichs

Beim Vergleich der Ausführungszeit von zwei verschiedenen Abfragen ist es wichtig, den Cache zu leeren, um sicherzustellen, dass die Ausführung der ersten Abfrage die Leistung der zweiten nicht verändert.

In einer Google-Suche konnte ich folgende Befehle finden:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

Tatsächlich benötigen meine Abfragen nach mehreren Ausführungen eine realistischere Zeit als zuvor. Ich bin mir jedoch nicht sicher, ob dies die empfohlene Technik ist.

Was ist die beste Vorgehensweise?

49
andrerpena

Persönlich sind für eine allgemeine Abfrage die zweite und nachfolgende Ausführung wichtiger.

Testen Sie disk IO oder die Abfrageleistung?

Angenommen, Ihre Abfrage wird häufig ausgeführt und ist kritisch, dann möchten Sie dies unter realen Bedingungen messen. Und Sie möchten die Prod-Server-Caches nicht jedes Mal löschen ...

Wenn Du willst, kannst Du:

  • DBCC DROPCLEANBUFFERS löscht saubere (unveränderte) Seiten aus dem Pufferpool
    Stellen Sie dem ein CHECKPOINT voran, um alle schmutzigen Seiten zuerst auf die Festplatte zu leeren
  • DBCC FLUSHPROCINDB löscht Ausführungspläne für diese Datenbank

Siehe auch (auf DBA.SE)

45
gbn

Späte Antwort, kann aber für andere Leser von Nutzen sein

DBCC DROPCLEANBUFFERS ist ein häufig verwendeter Befehl zum Testen von Abfragen und zum Messen der Ausführungsgeschwindigkeit von Abfragen. Dieser Befehl (wenn ausgeführt) hinterlässt nur die schmutzigen Seiten, bei denen es sich tatsächlich um einen kleinen Teil der Daten handelt. Es werden alle sauberen Seiten für einen gesamten Server entfernt.

Beachten Sie, dass dieser Befehl nicht in der Produktionsumgebung ausgeführt werden sollte. Das Ausführen dieses Befehls führt zu einem größtenteils leeren Puffercache. Ausführen einer Abfrage nach dem Ausführen von DBCC DROPCLEANBUFFERS Befehl verwendet physische Lesevorgänge, um die Daten in den Cache zurückzubringen, der sehr wahrscheinlich viel langsamer als der Speicher sein wird.

Behandeln Sie diesen Befehl erneut ähnlich wie DBCC FREEPROCCACHE - Es sollte nicht auf einem Produktionsserver ausgeführt werden, es sei denn, Sie wissen absolut, was Sie tun.

Dies kann ein nützliches Entwicklungstool sein, da Sie eine Abfrage in einer Leistungstestumgebung immer wieder ausführen können, ohne dass sich die Geschwindigkeit/Effizienz aufgrund des Zwischenspeicherns von Daten im Speicher ändert.

Weitere Informationen finden Sie unter: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

15
Thomas Bovee

Mir wurde immer gesagt:

dbcc dropcleanbuffers;

Von MSDN :

Verwenden Sie DBCC DROPCLEANBUFFERS, um Abfragen mit einem Cold-Buffer-Cache zu testen, ohne den Server herunterzufahren und neu zu starten.

Verwenden Sie CHECKPOINT, um saubere Puffer aus dem Pufferpool zu löschen und einen kalten Puffercache zu erstellen. Dadurch werden alle fehlerhaften Seiten für die aktuelle Datenbank auf die Festplatte geschrieben und die Puffer bereinigt. Nachdem Sie dies getan haben, können Sie den Befehl DBCC DROPCLEANBUFFERS ausgeben, um alle Puffer aus dem Pufferpool zu entfernen.

10
DaveShaw

Die anderen Antworten sind in Bezug auf Gründe für nicht run DBCC FREEPROCCACHE. Es gibt jedoch auch einige Gründe dafür:

  1. Konsistenz

Wenn Sie zwei verschiedene Abfragen oder Prozeduren vergleichen möchten, die versuchen, dasselbe auf unterschiedliche Weise zu tun, werden sie wahrscheinlich dieselben Seiten aufrufen. Wenn Sie die Abfrage Nr. 1 naiv und dann die Abfrage Nr. 2 ausführen, ist die zweite möglicherweise viel schneller, da diese Seiten von der ersten Abfrage zwischengespeichert wurden. Wenn Sie den Cache vor jeder Ausführung leeren, beginnen sie auf einer gleichmäßigen Grundlage.

Wenn Sie die Hot-Cache-Leistung testen möchten, müssen Sie die Abfragen mehrmals abwechselnd ausführen und die ersten paar Läufe verwerfen. Durchschnitt der Ergebnisse.

  1. Worst-Case-Leistung

Angenommen, Sie haben eine Abfrage, die für einen heißen Cache eine Sekunde, für einen kalten Cache jedoch eine Minute dauert. Eine Optimierung, die die speicherinterne Abfrage um 20% langsamer macht, die E/A-gebundene Abfrage jedoch um 20% schneller, könnte ein großer Gewinn sein: Während des normalen Betriebs wird niemand die zusätzlichen 200 ms unter normalen Umständen bemerken, aber wenn etwas eine Abfrage dazu zwingt Wenn Sie 48 Sekunden anstatt 60 Sekunden auf der Festplatte ausführen, wird möglicherweise ein Verkauf gerettet.

Dies ist auf modernen Systemen mit mehreren zehn Gigabyte Speicher und relativ schnellem SAN und SSD-Speicher) weniger bedenklich, aber es ist immer noch wichtig. Wenn ein Analyst eine massive Tabellenscan-Abfrage für Ihr = ausführt OLTP-Datenbank, die die Hälfte Ihres Puffercaches löscht. Speichereffiziente Abfragen bringen Sie schneller wieder auf den neuesten Stand.

3