In SQL Server ist der Puffercache der Speicher, der es Ihnen ermöglicht, häufig aufgerufene Daten schnell abzufragen. Wenn Daten in eine SQL Server-Datenbank geschrieben oder daraus gelesen werden, kopiert der Puffermanager sie in den Puffercache (auch als Pufferpool bezeichnet). Wenn sie voll ist, werden ältere oder weniger häufig verwendete Datenseiten auf die Festplatte verschoben.
Warum muss ich den Puffercache überwachen?
Die Speichernutzung kann sich erheblich auf die Leistung auswirken. Wenn nicht genügend Speicher vorhanden ist, werden Datenseiten häufig aus dem Puffercache gelöscht. Dadurch werden Abfragen verlangsamt, da SQL Server auf die Festplatte gehen muss, um die Datenseite zu finden, sie im Puffercache wiederherzustellen und dann die Seite zu lesen, bevor Abfrageergebnisse zurückgegeben werden können.
Es gibt viele Gründe, warum Abfragen langsam ausgeführt werden. Aber wenn Sie Speicherprobleme ausschließen wollen, sehen Sie sich an, was im Buffer-Cache vor sich geht. Ein Blick hinein wird erkennen, welche Datenbank, Tabelle oder welcher Index Speicher belegt und Druck auf den Puffer ausübt.
Um zu sehen, welche Datenbank den meisten Speicher verbraucht, verwenden Sie die Abfrage:
SELECT CASE database_id WHEN 32767 THEN 'ResourceDb' ELSE db_name(database_id) END AS database_name, COUNT(1)/128 AS megabytes_in_cache FROM sys.dm_os_buffer_descriptors GROUP BY DB_NAME(database_id) ,database_id ORDER BY megabytes_in_cache DESC;
Führen Sie diese Abfrage in der Datenbank aus, die Sie untersuchen möchten, um die Tabelle oder den Index zu ermitteln, die bzw. der den meisten Speicher verbraucht:
SELECT COUNT(1)/128 AS megabytes_in_cache ,name ,index_id FROM sys.dm_os_buffer_descriptors AS bd INNER JOIN ( SELECT object_name(object_id) AS name ,index_id ,allocation_unit_id FROM sys.allocation_units AS au INNER JOIN sys.partitions AS p ON au.container_id = p.hobt_id AND (au.type = 1 OR au.type = 3) UNION ALL SELECT object_name(object_id) AS name ,index_id, allocation_unit_id FROM sys.allocation_units AS au INNER JOIN sys.partitions AS p ON au.container_id = p.partition_id AND au.type = 2 ) AS obj ON bd.allocation_unit_id = obj.allocation_unit_id WHERE database_id = DB_ID() GROUP BY name, index_id ORDER BY megabytes_in_cache DESC;
Speicher mit Metriken verwalten
Obwohl es hilfreich ist, Datenbanken und Indizes stichprobenartig auf Überbeanspruchung des Arbeitsspeichers zu überprüfen, ist das Verfolgen von Puffer-Cache-Metriken wirklich der beste Weg, um Leistungsprobleme zu identifizieren und zu lösen, die durch internen Druck auf den Arbeitsspeicher verursacht werden.
Hier sind die fünf wichtigsten Metriken, die Sie überwachen sollten, um speicherbezogene Leistungsprobleme zu verbessern:
1. Puffer-Cache-Trefferquote
- Diese Metrik zeigt, wie SQL Server den Puffercache nutzt
- Die Trefferquote gibt den Prozentsatz der Seitenanforderungen an, die von Datenseiten aus dem Puffercache im Vergleich zu allen Datenseitenanforderungen abgeschlossen wurden
- Seiten, die nicht im Puffer-Cache gefunden werden, werden von der Festplatte gelesen, was viel langsamer ist
- Das ideale Puffer-Cache-Verhältnis ist 100 (d. h. SQL Server liest alle Seiten aus dem Puffer-Cache und keine von der Festplatte)
- Der empfohlene Puffer-Cache-Wert ist größer als 90
2. Seitenlebenserwartung (PLE)
- Die Seitenlebenserwartung misst, wie lange (in Sekunden) eine Datenseite im Puffercache verbleibt
- Je länger die PLE, desto größer die Chance, dass SQL Server die Seiten aus dem Puffercache liest und nicht auf die Festplatte gehen muss
- Wenn nicht genügend Speicher vorhanden ist, werden Datenseiten häufiger aus dem Puffercache geleert, um Platz für neue Seiten zu schaffen
- In der Vergangenheit lag ein „normaler“ PLE-Wert bei 300 Sekunden, als Systeme weit weniger Arbeitsspeicher hatten als heute
- Heute wird eine Formel verwendet, um „gute“ PLE zu bestimmen:Seitenlebenserwartung =300 Sekunden pro 4 GB RAM auf Ihrem Server
- Der PLE sollte bei längerer Überwachung stabil bleiben
- Schnelle, häufige Abnahmen weisen auf Speicherprobleme hin
- Ein Abfall von mehr als 50 % sollte sofort untersucht werden
3. Seitenlesevorgänge/Sek. (Serverebene)
- Diese Metrik zeigt, wie viele physische Lesevorgänge (d. h. Lesevorgänge von der Festplatte) in einer Sekunde in allen Datenbanken einer Instanz erfolgten
- Physische Lesevorgänge sind teuer und langsam
- Reduzieren Sie physische Lesevorgänge, indem Sie einen größeren Datencache, intelligente Indizes und effizientere Abfragen verwenden oder das Datenbankdesign ändern
- Der empfohlene Wert liegt unter 90
- Ein Wert über 90 weist auf unzureichenden Arbeitsspeicher und Indizierungsprobleme hin
4. Seitenschreibvorgänge/Sek.
- Diese Metrik zeigt, wie oft Seiten innerhalb einer Sekunde auf Serverebene auf die Festplatte geschrieben wurden
- Der empfohlene Wert liegt unter 90
5. Seiteneingabe/Sek. und Seitenausgabe/Sek. (Speicherzähler)
- Eingegebene Seiten/Sek. ist die Anzahl der Seiten, die jede Sekunde von der Festplatte importiert werden
- Seitenausgabe/Sek. ist die Anzahl der Seiten, die jede Sekunde auf die Festplatte geschrieben werden, um Platz im Puffer-Cache zu schaffen
- Seiten/Sek. ist die Summe aus Seiteneingabe/Sek. und Seitenausgabe/Sek.
- Wenn der Wert für Seiten/Sek. dauerhaft über 50 liegt, sind weitere Untersuchungen erforderlich
Ein fehlerfreier Puffercache ist eine wichtige Komponente bei der Optimierung der Abfragegeschwindigkeit von SQL Server. Obwohl Speicherprobleme nur einer von mehreren Faktoren sind, die Abfrageantworten verlangsamen können, sind sie ziemlich einfach zu identifizieren und zu beheben. Das Verfolgen dieser fünf Schlüsselmetriken kann Ihnen dabei helfen, Datenseiten länger im Pufferpool zu halten, sodass SQL Server keine Zeit damit verschwenden muss, die Festplatte zu durchsuchen, bevor Abfrageergebnisse zurückgegeben werden.
