Que dit Page Life Expectancy sur l'instance?

J'ai installé un logiciel de surveillance sur quelques instances de SQL Server dans l'environnement. J'essaie de trouver des goulots d'étranglement et de résoudre certains problèmes de performances. Je veux savoir si certains serveurs ont besoin de plus de mémoire.

Je m'intéresse à un compteur: l'espérance de vie de la page. Il semble différent sur chaque machine. Pourquoi cela change-t-il souvent dans certains cas et qu'est-ce que cela signifie?

Veuillez consulter les données de la semaine dernière recueillies sur quelques machines différentes. Que pouvez-vous dire sur chaque instance?

Instance de production très utilisée (1):

Production moyennement utilisée (2)

Instance de test rarement utilisée (3)

Instance de production très utilisée (4)

Instance de test moyennement utilisée (5)

Entrepôt de données très utilisé (6)

EDIT: J'ajoute la sortie de SELECT @@ VERSION pour tous ces serveurs:

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)

J'ai également exécuté la requête suivante sur les machines:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

et il a renvoyé 2 ou 3 lignes pour chaque serveur:

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

Qu'est-ce que ça veut dire? Ces serveurs exécutent-ils NUMA?

Tiré de MSDN: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

Espérance de vie de la page - Indique le nombre de secondes pendant lesquelles une page restera dans le pool de mémoire tampon sans références.

SQL recherche toujours les pages de données en mémoire. Si une page de données n'est pas en mémoire, SQL devra aller sur le disque (effectuer une opération d'E / S physique) afin de récupérer les données dont il a besoin pour répondre à une demande. Si votre compteur PLE est faible, cela indique que les pages de données en mémoire sont régulièrement remplacées par de nouvelles pages provenant d'opérations d'E / S physiques. Les opérations d'E / S physiques sont coûteuses, ce qui signifie que les performances de votre instance SQL seront affectées. Vous voudrez donc que votre compteur PLE soit aussi élevé que possible.

Ignorez tout conseil que vous voyez en ligne qui mentionne 300 comme un bon seuil pour ce compteur

Ce seuil vient des jours où la mémoire était limitée (pensez aux systèmes 32 bits). Nous avons maintenant des systèmes 64 bits qui peuvent avoir des To de RAM, donc ce conseil est très dépassé.

Première chose, avez-vous limité la mémoire de SQL? Si oui, combien de mémoire disponible reste-t-il? La limite peut-elle être augmentée?

La deuxième chose que je rechercherais sur vos serveurs est la suivante: y a-t-il des travaux de maintenance en cours? Recherchez les travaux effectuant les reconstructions d'index, les statistiques de mise à jour ou les opérations DBCC CHECKDB. Ceux-ci effectuent une grande quantité de lectures et pourraient être la raison de votre doublure plate PLE,

Ensuite, lorsque vous utilisez SQL Server 2008 +, vous pouvez configurer une session d'événement étendu pour capturer les requêtes entrantes qui effectuent une grande quantité de lectures. Voici le code pour le faire: -

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

Cela capturera toutes les requêtes sur votre serveur qui effectuent plus de 200 000 lectures logiques. Je ne sais pas combien de mémoire vous avez sur chaque serveur, vous voudrez peut-être modifier ce chiffre. Une fois celui-ci créé, vous pouvez démarrer la session en exécutant: -

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

Et puis interrogez la session en exécutant: -

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

Soyez prudent lorsque vous exécutez cela! Le fichier peut devenir assez volumineux, testez-le d'abord sur une instance de développement. Vous pouvez définir le max. taille du fichier mais je ne l'ai pas inclus ici. Voici le lien MSDN pour les événements étendus: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

Surveillez régulièrement cette session et, espérons-le, elle devrait détecter toutes les requêtes entrantes qui sont à plat sur votre PLE.

Lectures complémentaires -

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

Vidéo sur la configuration des événements étendus - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ (C'est de mon propre blog, donc désolé pour l'autopromotion sans vergogne) )

L'espérance de vie de la page est une mesure de combien de temps vous pouvez vous attendre à ce qu'une page qui vient d'être lue sur le disque reste en mémoire avant d'être poussée par quelque chose d'autre ou d'être détruite (c'est-à-dire que cette page est désallouée sur le disque pour qu'il n'y ait pas besoin pour conserver une copie en cache dans la RAM).

En règle générale, plus il est élevé, plus votre schéma de charge sera traité rapidement car les choses sont conservées en mémoire. Si elle est très faible, cela pourrait indiquer un problème de performances provoqué par un manque de mémoire.

Cependant, la lecture faible ne signifie pas toujours qu'il y a un problème: par exemple, il pourrait être faible après une surabondance massive de processus qui utilisaient beaucoup de pages, alors faites-les entrer et laissez-les tomber pour faire de la place pour plus. Votre graphique qui semble baisser à la fin de chaque journée par exemple, pourrait être dû à des tâches administratives nocturnes (sauvegarde, archivage des données, autres traitements de nuit).