Was sagt Page Life Expectancy über die Instanz aus?

Ich habe Überwachungssoftware auf einigen SQL Server-Instanzen in der Umgebung installiert. Ich versuche, Engpässe zu finden und einige Leistungsprobleme zu beheben. Ich möchte herausfinden, ob einige Server mehr Speicher benötigen.

Ich interessiere mich für einen Zähler: die Lebenserwartung der Seite. Auf jeder Maschine sieht es anders aus. Warum ändert es sich in einigen Fällen häufig und was bedeutet es?

Bitte werfen Sie einen Blick auf die Daten der letzten Woche, die auf verschiedenen Maschinen gesammelt wurden. Was können Sie zu jeder Instanz sagen?

Stark genutzte Produktionsinstanz (1):

Mäßig genutzte Produktionsleistung (2)

Selten verwendete Testinstanz (3)

Stark genutzte Produktionsinstanz (4)

Mäßig verwendete Testinstanz (5)

Stark genutztes Data Warehouse (6)

EDIT: Ich füge die Ausgabe von SELECT @@ VERSION für alle diese Server hinzu:

Instance 1: Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 
Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 2: Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 
Oct 19 2012 13:38:57 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 3: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
    Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 4: Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 5: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 6: Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr 2 2010 15:48:46 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Ich habe auch die folgende Abfrage auf den Maschinen ausgeführt:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

und es gab 2 oder 3 Zeilen für jeden Server zurück:

Instance 1: 0; 64; 1
Instance 2: 0; 64
Instance 3: 0; 64
Instance 4: 0; 64
Instance 5: 0; 64
Instance 6: 0; 64; 1

Was bedeutet es? Führen diese Server NUMA aus?

Entnommen aus MSDN: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

Seitenlebenserwartung - Gibt an, wie viele Sekunden eine Seite ohne Referenzen im Pufferpool verbleibt.

SQL sucht immer nach Datenseiten im Speicher. Wenn sich eine Datenseite nicht im Speicher befindet, muss SQL auf die Festplatte gehen (eine physische E / A-Operation ausführen), um die Daten abzurufen, die zur Erfüllung einer Anforderung erforderlich sind. Wenn Ihr PLE-Zähler niedrig ist, bedeutet dies, dass Datenseiten im Speicher regelmäßig mit neuen Seiten überschrieben werden, die aus physischen E / A-Vorgängen stammen. Physische E / A-Vorgänge sind teuer, was bedeutet, dass die Leistung Ihrer SQL-Instanz beeinträchtigt wird. Sie möchten also, dass Ihr PLE-Zähler so hoch wie möglich ist.

Ignorieren Sie alle Ratschläge, die Sie online sehen und die 300 als guten Schwellenwert für diesen Zähler angeben

Dieser Schwellenwert stammt aus den Tagen, als der Speicher begrenzt war (denken Sie an 32-Bit-Systeme). Jetzt haben wir 64-Bit-Systeme, die TBs RAM haben können, daher ist dieser Rat sehr veraltet.

Haben Sie als erstes den Speicher von SQL eingeschränkt? Wenn ja, wie viel verfügbarer Speicher ist noch vorhanden? Kann das Limit erhöht werden?

Das zweite, wonach ich auf Ihren Servern suchen würde, ist, ob Wartungsjobs ausgeführt werden. Suchen Sie nach Jobs, die Indexwiederherstellungen durchführen, Statistiken aktualisieren oder DBCC CHECKDB-Vorgänge ausführen. Diese führen eine große Anzahl von Lesevorgängen durch und könnten der Grund für Ihr PLE-Flachfutter sein.

Als Nächstes können Sie bei Verwendung von SQL Server 2008 + eine erweiterte Ereignissitzung einrichten, um eingehende Abfragen zu erfassen, die eine große Anzahl von Lesevorgängen ausführen. Hier ist der Code dazu: -

CREATE EVENT SESSION [QueriesWithHighLogicalReads] ON SERVER 
ADD EVENT sqlserver.sql_batch_completed(
   ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username)
     WHERE ([logical_reads]>200000))
ADD TARGET package0.event_file(SET filename=N'C:\SQLServer\XEvents\QueriesWithHighLogicalReads.xel')
GO

Dadurch werden alle Abfragen auf Ihrem Server erfasst, die über 200000 logische Lesevorgänge ausführen. Ich weiß nicht, wie viel Speicher Sie auf jedem Server haben, daher möchten Sie diese Zahl möglicherweise anpassen. Sobald dies erstellt wurde, können Sie die Sitzung starten, indem Sie Folgendes ausführen: -

ALTER EVENT SESSION [QueriesWithHighLogicalReads]
ON SERVER
STATE = START;
GO

Fragen Sie dann die Sitzung ab, indem Sie Folgendes ausführen: -

WITH CTE_ExecutedSQLStatements AS
(SELECT
[XML Data],
[XML Data].value('(/event[@name=''sql_statement_completed'']/@timestamp)[1]','DATETIME')    AS [Time],
[XML Data].value('(/event/data[@name=''duration'']/value)[1]','int')                        AS [Duration],
[XML Data].value('(/event/data[@name=''cpu_time'']/value)[1]','int')                        AS [CPU],
[XML Data].value('(/event/data[@name=''logical_reads'']/value)[1]','int')                   AS [logical_reads],
[XML Data].value('(/event/data[@name=''physical_reads'']/value)[1]','int')                  AS [physical_reads],
[XML Data].value('(/event/action[@name=''sql_text'']/value)[1]','varchar(max)')             AS [SQL Statement]
FROM
    (SELECT 
    OBJECT_NAME              AS [Event], 
    CONVERT(XML, event_data) AS [XML Data]
FROM 
    sys.fn_xe_file_target_read_file
('C:\SQLServer\XEvents\QueriesWithHighLogicalReads*.xel',NULL,NULL,NULL)) as v)

SELECT
[SQL Statement]     AS [SQL Statement],
SUM(Duration)       AS [Total Duration],
SUM(CPU)            AS [Total CPU],
SUM(Logical_Reads)  AS [Total Logical Reads],
SUM(Physical_Reads) AS [Total Physical Reads]
FROM
CTE_ExecutedSQLStatements
GROUP BY
[SQL Statement]
ORDER BY
[Total Logical Reads] DESC
GO

Seien Sie vorsichtig, wenn Sie dies ausführen! Die Datei kann sehr groß werden. Testen Sie sie daher zuerst auf einer Entwicklungsinstanz. Sie können die max. Größe der Datei, aber ich habe das hier nicht aufgenommen. Hier ist der MSDN-Link für erweiterte Ereignisse: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

Überwachen Sie diese Sitzung routinemäßig und hoffentlich werden alle eingehenden Fragen erfasst, die Ihren PLE betreffen.

Weiterführende Literatur -

MSDN-Blog auf PLE - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx

Video zum Einrichten erweiterter Ereignisse - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ (Es stammt aus meinem eigenen Blog und entschuldigt die schamlose Eigenwerbung )

Die Lebenserwartung von Seiten ist ein Maß dafür, wie lange eine Seite, die gerade von der Festplatte gelesen wurde, im Speicher hängen bleibt, bevor sie von etwas anderem herausgeschoben oder zerstört wird (dh diese Seite wird auf der Festplatte freigegeben, ohne dass dies erforderlich ist um eine Kopie im RAM zwischengespeichert zu halten).

Im Allgemeinen gilt: Je höher es ist, desto schneller wird Ihr Lademuster verarbeitet, da die Dinge im Speicher bleiben. Wenn es sehr niedrig ist, kann dies auf ein Leistungsproblem hinweisen, das durch Speichermangel verursacht wird.

Der niedrige Messwert bedeutet jedoch nicht immer, dass es ein Problem gibt: Zum Beispiel könnte er nach einer massiven einmaligen Flut von Prozessen, bei denen viele Seiten verwendet wurden, niedrig sein. Lassen Sie sie also einbringen und löschen, um Platz für mehr zu schaffen. Ihr Diagramm, das beispielsweise am Ende eines jeden Tages zu fallen scheint, kann durch nächtliche Verwaltungsaufgaben (Sicherung, Datenarchivierung, andere Verarbeitung über Nacht) verursacht werden.