Qu'est-ce que l'espérance de vie de la page dit à propos de l'instance?
J'ai installé un logiciel de surveillance sur quelques instances SQL Server dans l'environnement. J'essaie de trouver des goulots d'étranglement et de résoudre certains problèmes de performance. Je veux savoir si certains serveurs ont besoin de plus de mémoire.
Je suis intéressé par un compteur: l'espérance de vie de la page. Il semble différent sur chaque machine. Pourquoi cela change-t-il souvent sur certains cas et que signifie-t-il?
Veuillez consulter les données de la semaine dernière recueillies sur quelques machines différentes. Que pouvez-vous dire à propos de chaque instance?
Instance de production fortement utilisée (1): 
Isance de production modérément utilisée (2) 
Instance de test rarement utilisée (3)
Instance de production fortement utilisée (4) 
Instance de test modérément utilisée (5) 
Entrepôt de données fortement utilisé (6) 
EDIT: im Ajout de 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 couru 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 rangées 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? Est-ce que ces serveurs fonctionnent 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 qu'une page restera dans la piscine tampon sans références.
SQL recherche toujours des pages de données en mémoire. Si une page de données n'est pas dans la mémoire SQL, SQL devra aller sur le disque (effectuer une opération physique IO) afin de récupérer les données nécessaires pour remplir une demande. Si votre compteur PLE est faible qui indique que les pages de données en mémoire sont régulièrement écrasées avec de nouvelles pages provenant des opérations physiques IO. Les opérations physiques IO sont coûteuses signifiant que la performance de votre instance SQL sera affectée négativement. Vous voudrez donc que votre compteur PLE soit aussi élevé que possible.
ignore tout conseil que vous voyez en ligne qui mentionne 300 comme bon seuil pour ce compteur
Ce seuil provient des jours où la mémoire était limitée (pensez 32 bits). Maintenant, nous avons des systèmes de 64 bits qui peuvent avoir des TBS de RAM afin que ce conseil soit très obsolète.
Première chose, avez-vous limité la mémoire de SQL? Si oui, combien de mémoire disponible est disponible? La limite peut-elle être augmentée?
La deuxième chose que je rechercherais sur vos serveurs est, existe-t-il des emplois de maintenance? Recherchez les travaux effectuant des reconstructions d'index, des statistiques de mise à jour ou des opérations DBCC CheckDB. Celles-ci effectuent une grande quantité de lecture et pourraient être la raison de votre doublure plate,
Ensuite, comme vous utilisez SQL Server 2008 +, vous pouvez configurer une session d'événement étendue pour capturer des requêtes en cours qui effectuent une grande quantité de lecture. 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 questions sur votre serveur qui effectuent plus de 200 000 lectures logiques. Je ne sais pas combien de mémoire vous avez sur chaque serveur afin que vous puissiez vouloir modifier ce chiffre. Une fois que cela a été créé, vous pouvez commencer la session en exécutant: -
ALTER EVENT SESSION [QueriesWithHighLogicalReads]
ON SERVER
STATE = START;
GO
Puis interroger la session en courant: -
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 courez ça! Le fichier peut devenir assez grand de taille, alors testez-le d'abord sur une instance de développement. Vous pouvez définir le max. taille du fichier mais je n'ai pas inclus cela ici. Voici le lien MSDN pour les événements étendus: - https://msdn.microsoft.com/en-us/library/hh213147.aspx
Surveillez cette session systématiquement et, espérons-le, il devrait récupérer toutes les questions qui arrivent à plates plats.
Lecture ultérieure -
MSDN Blog sur PLE - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectrogan.aspx
Vidéo sur la configuration des événements étendus https://dbafromthecold.wordpress.com/2014/12/05/video-Identifiant-large-queries-utilisant-extended-events/ (c'est de mon propre blog Désolé pour la promotion auto sans vergogne)
L'espérance de vie de la page est une mesure de la durée de laquelle vous pouvez vous attendre à une page qui vient d'être lue à partir du disque pour accrocher en mémoire avant d'être repoussée par quelque chose d'autre ou est détruit (c'est-à-dire que cette page est traitée sur le disque sur le disque. garder une copie mise en cache dans la RAM).
En tant que mesure générale, plus il est plus élevé que votre motif de charge sera traité, car les choses sont conservées en mémoire. S'il est très faible, cela pourrait indiquer un problème de performance causé par la famine de mémoire.
La lecture étant faible ne signifie pas toujours qu'il y a un problème cependant: par exemple, il pourrait être faible après une feuille de procédés montagneux massive qui utilisait de nombreuses pages, ce qui les a amenés et ils ont chuté pour faire de la place plus. Votre graphique qui semble chuter à la fin de chaque jour par exemple, pourrait être causé par des emplois administratifs nocturnes (sauvegarde, archivage de données, autres traitement de la nuit).