it-swarm.com.de

Page Life Expectancy (PLE), wo soll ich anfangen?

Ich habe einen SQL Server geerbt { 2012 (SP3), aber diese Frage soll generisch sein} Wir verwenden SCOM, um ihn zu überwachen. Früher wurde ich ein- oder zweimal im Monat für PLE <300 alarmiert. Jetzt bekomme ich manchmal zwei oder drei pro Tag.

Es gibt mehrere Blog-Beiträge über PLE, einige Tools, mit denen Sie es überwachen können, und viele unterschiedliche Meinungen darüber, was gut, schlecht oder gleichgültig ist. Am Ende gibt es viele Variablen. Keine Lösung ist eine Größe für alle. Ein niedriger PLE ist weniger ein Problem als vielmehr ein Symptom mit vielen möglichen Ursachen und damit verbundenen Maßnahmen.

{ Dieser Absatz bietet möglicherweise keinen Mehrwert für die Frage. Ich bin offen dafür, ihn zu entfernen. } Ich denke, jeder kann zustimmen, dass PLE einmal im Monat auf 299 fällt Eine Berichterstellung über Nacht ist ein Symptom, das nicht behoben werden muss ( vorausgesetzt, der Bericht wird vor Geschäftsschluss fertiggestellt). Die meisten können auch zustimmen, dass PLE konstant bei 350 nicht gut ist. Es gibt eine Handvoll Gründe, die Sie prüfen sollten, bevor Sie Hardwareänderungen vornehmen. Abfragen und Index befinden sich ganz oben.

Nach dem Lesen von etwa einem Dutzend Blog-Posts über PLE. Ich habe versucht, die wichtigsten Symptome einzugrenzen, um ein gutes Bild davon zu bekommen, was vor sich geht. Die folgende Abfrage ist das, was ich mir ausgedacht habe. Es gibt Werte für 4 Buffer Manager-Elemente an, die mit PLE verbunden sind

  • 'Lebenserwartung der Seite'
  • 'Kostenlose Listenstände/Sek.'
  • 'Lazy schreibt/Sek.'
  • 'Puffer-Cache-Trefferquote'

...

SELECT [object_name],
[counter_name],
[cntr_value] FROM sys.dm_os_performance_counters -- https://docs.Microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-performance-counters-transact-sql
WHERE [counter_name] = 'Page life expectancy' --if multiple NUMA on a server should return multiple Nodes, 
OR [counter_name] = 'Free list stalls/sec'  -- Number of requests per second that had to wait for a free page https://docs.Microsoft.com/en-us/sql/relational-databases/performance-monitor/sql-server-buffer-manager-object
OR [counter_name] = 'Lazy writes/sec' --Flushes of dirty pages before a checkpoint runs.  
OR [counter_name] = 'Buffer cache hit ratio' --percentage of pages found in the buffer cache without having to read from disk you want this ratio to be high
Order by [counter_name] DESC, [object_name];

Wenn Sie sich Lazy Writes auf einem geerbten Server ansehen, sollten Sie außerdem das Wiederherstellungsintervall überprüfen

EXEC sp_configure @configname='recovery interval (min)';  --The  'config_value' default 0 indicates SQL is applying Checkpoints completely automatically https://docs.Microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-recovery-interval-server-configuration-option

Wenn diese erste Abfrage keine Werte zurückgibt:

SELECT COUNT(*) FROM sys.dm_os_performance_counters;  --If no values from the firs query, an value of 0 here indicates a seperate issue  https://docs.Microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-performance-counters-transact-sql

Ich habe eine ziemlich gute Vorstellung davon, was all diese Werte darstellen und wie sie zusammenarbeiten. Ich habe Kommentare und Quellen in meinen obigen Code aufgenommen.

Meine Frage besteht aus zwei Teilen

  1. Ist meine Liste der Pufferelemente/-werte oben für einen Startplatz bei der Untersuchung von PLE ausreichend? ( d. h. Werte, die immer hilfreich sind, um sie zusammen zu betrachten, sollte etwas ausgeschlossen oder eingeschlossen sein)

  2. Wie können die Werte in einen guten Kontext zueinander gestellt werden? ( dh es gibt ein gutes Antwort hier mit der Aufschrift "Überprüfen Sie auch den Wert für Free List Stalls/sec. Wenn über 2, erwägen Sie, dem Server Speicher hinzuzufügen" , während der Hauptteil der Antwort lautet hilfreich, ich denke nicht, dass ein Wert von 2 für 'Free List Stalls/sec' in den meisten Fällen ein Problem ist)

HINWEIS: Bei dieser Frage geht es nicht um die Lösung des PLE-Problems, sondern darum, wie/wo bei der Beurteilung der Symptome zu suchen ist. Ihr Arzt überprüft zu Beginn jeder Untersuchung Ihre Pules, Ihren Blutdruck, Ihre Atmung und Ihre Temperatur.

Bearbeiten 13.04.2008; Versuch zu klären Hier geht es nicht um Knie-Ruck-Reaktionen wie das Überprüfen von Indizes oder Wartezeiten. Hier geht es darum, andere native SQL-Leistungsdaten zu identifizieren, die immer mit PLE untersucht werden sollten. PLE ist eines der Pufferverwaltungsobjekte. Welche anderen Pufferverwaltungsobjekte oder Leistungsindikatoren sollten oder sollten nicht immer Teil von Abfragen sein, wenn Sie sich wirklich mit der Pufferverwaltung befassen möchten?

7
James Jenkins

Sie haben im Grunde gefragt: "Was soll ich tun, wenn sich die Lebenserwartung der Seite ändert?"

Meine Antwort: nichts. Ich beginne nicht mit dem Blick auf die Lebenserwartung von Seiten. Diese Metrik machte in den SQL Server 7/2000 Tagen Sinn, als es alles war, was wir hatten, aber heute, im Jahr 2018, können wir es besser machen.

Schauen Sie sich zunächst die Wartestatistiken an - hier erfahren Sie, worauf SQL Server wartet.

Es ist mir egal, ob PLE 300 oder 3.000 ist - sagen Sie mir, worauf Sie warten, SQL Server, und dann werde ich diese Metrik beheben.

Meine persönliche Lieblingsmethode zum Überprüfen von Wartezeiten ist die Verwendung von Open Source sp_BlitzFirst (Haftungsausschluss: Ich habe es geschrieben.) Standardmäßig wird ein 5-Sekunden-Beispiel der Metriken Ihres Servers verwendet, und Sie erhalten einige Vermutungen als warum es gerade langsam ist.

Da Sie gerne lange Fragen schreiben, werden Ihnen wahrscheinlich auch diese gefallen:

sp_BlitzFirst @SinceStartup = 1;

Die erste Ergebnismenge gibt Ihnen Ihre Wartezeiten seit dem Start und:

sp_Blitz @ExpertMode = 1, @Seconds = 60;

Nimmt eine längere Probe und teilt Ihre Wartezeiten über diesen Zeitraum mit.

Wartestatistiken können kryptisch sein, daher verweise ich neben jedem Wartetyp auf das SQLskills-Wartestatistik-Repository für diesen Wartetyp. Sie können einfach den Namen Ihres Top-Wartetyps kopieren/einfügen, zu dessen Site gehen und mehr darüber erfahren, welche Ursachen das Warten verursacht und wie es behoben werden kann.

Wenn PLE beispielsweise aufgrund von Abfragen, die viele Datenseiten von der Festplatte lesen, gelöscht wird, werden möglicherweise PAGEIOLATCH% -Wartetypen angezeigt. Wenn es aufgrund von Abfragen, die große Speicherzuweisungen erhalten, gelöscht wird, wird möglicherweise RESOURCE_SEMAPHORE angezeigt. Wenn PLE nicht das Problem ist, werden insgesamt verschiedene Wartetypen angezeigt.

15
Brent Ozar

Es ist eine Weile her, seit ich diese Frage gestellt habe, ich habe seitdem viel gelernt.

Wie Brent in hervorhebt, sagt Ihnen seine Antwort PLE-Warnungen selbst nichts. Diese Seiten sollten von Natur aus kommen und gehen. Wenn sie nicht lange bleiben, wenn sie nicht mehr benötigt werden, ist das in Ordnung.

Trotzdem habe ich eine bestimmte Instanz, die mehrmals täglich PLE-Warnungen auslöst. Ich habe sie mit verschiedenen Tools einschließlich des Abfragespeichers betrachtet und nichts gefunden, was Aufmerksamkeit erfordert. Selbst wenn ich Speicher hinzugefügt habe, sieht es nicht so aus, als würden die PLE-Warnungen aufhören. Ich suchte nach einem Weg, um zu "beweisen", ob mehr Speicher benötigt wurde oder nicht.

Auf kleinen SQL-Instanzen mit 4 GB verfügbarem RAM können 75% oder 3 GB für den Plan-Cache reserviert werden. Normalerweise wird dies [~ # ~] nicht [~ # ~] mit Datenseiten gelöscht, auf die PLE hinweist. Ich habe ein paar Möglichkeiten gefunden, um zu sehen, was mit dem Speicher und dem Plan-Cache passiert.

Letztendlich habe ich ( Nutzung der obigen Links) die folgende Abfrage entwickelt, die die Lebenserwartung (in Minuten) für Cache-Pläne zeigt.

    --plan cache Life expectancy
    SELECT sys.dm_exec_cached_plans.objtype AS [CacheType] 
    ,    COUNT_BIG(*) AS [Total Plans]
    ,    SUM(CAST(sys.dm_exec_cached_plans.size_in_bytes AS DECIMAL(18, 2))) / 1024 / 1024 AS [Total MBs]
    ,   AVG(sys.dm_exec_cached_plans.usecounts) AS [Avg Use Count]
    ,   AVG (DATEDIFF(MINUTE, PH_Time.creation_time, (GETDATE()))) AS [Avg Age in Minutes]
    FROM sys.dm_exec_cached_plans
    left join (
                Select  plan_handle
                , Min (creation_time) as creation_time --A plan can have several unique related quiries, this gets just one time per plan
                from sys.dm_exec_query_stats
                group by plan_handle
                ) as PH_Time On sys.dm_exec_cached_plans.plan_handle = PH_Time.plan_handle
    --left join sys.dm_exec_query_stats On sys.dm_exec_cached_plans.plan_handle = sys.dm_exec_query_stats.plan_handle 
    GROUP BY objtype
    ORDER BY [Total MBs] DESC
    GO

Obwohl kein einzelnes Element für sich genommen schlüssig ist, kann ein starkes Argument dafür angeführt werden, dass kein zusätzlicher Speicher benötigt wird, wenn die durchschnittliche Lebensdauer von Plänen im Cache länger ist als die Zeit zwischen der erneuten Ausführung von Abfragen. Die spezifische Zeit wird sehr vom Anwendungsfall abhängen.

Es gibt viele Gründe, warum Pläne neu kompiliert werden, siehe verwandte Warum fehlen im Query Store Details? Schon früh habe ich mich stark auf die hohe Neukompilierung mit PLE konzentriert und keine gefunden hilfreiche Korrelation.

TL: DR Der Speicher soll Dinge kommen und gehen lassen, niedriger PLE ist kein Problem. [~ # ~] aber [~ # ~] Von Natur aus sollten häufig verwendete Pläne lange genug im Speicher bleiben, um wiederverwendet zu werden. Wenn Sie nachweisen können, dass Pläne lange genug im Speicher verbleiben, um wiederverwendet zu werden, ist es schwierig, das Hinzufügen von Speicher ohne einen anderen Indikator zu rechtfertigen.

1
James Jenkins