web-dev-qa-db-fra.com

Page Espérance de vie (PLE), par où commencer?

J'ai hérité d'un serveur SQL { 2012 (SP3), mais cette question est destinée à être générique} nous utilisons SCOM pour le surveiller. Auparavant, je recevais une ou deux fois par mois une alerte pour un PLE <300. Maintenant, j'en reçois parfois 2 ou 3 par jour.

Il existe plusieurs articles de blog sur PLE, quelques outils que vous pouvez obtenir pour le surveiller et de nombreuses opinions divergentes sur ce qui est bon, mauvais ou indifférent. Au final, il y a beaucoup de variables. Aucune solution n'est unique. Un PLE faible n'est pas tant un problème qu'un symptôme, avec de nombreuses causes potentielles et des mesures connexes à considérer.

{ ce paragraphe peut ne pas ajouter de valeur à la question, je suis prêt à le supprimer } Je pense que tout le monde peut accepter que le PLE tombe à 299 une fois par mois pendant une création de rapport du jour au lendemain, est un symptôme qui n'a pas besoin d'être résolu ( en supposant que le rapport se termine avant les heures de bureau). La plupart peuvent également convenir que PLE, à 350, n'est pas bon. Il y a une poignée de raisons à examiner avant d'effectuer un changement de matériel, les requêtes et index étant proches du sommet.

Après avoir lu une douzaine d'articles de blog sur PLE. J'ai essayé de réduire les principaux symptômes pour avoir une bonne idée de ce qui se passe. La requête ci-dessous est ce que j'ai trouvé. Il donne des valeurs pour 4 éléments Buffer Manager qui s'interconnectent avec PLE

  • "Espérance de vie de la page"
  • "Liste des stands gratuits/sec"
  • "Écrit paresseux/sec"
  • "Taux de réussite du cache du tampon"

...

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];

De plus, si vous recherchez des écritures paresseuses sur un serveur hérité, vous devez vérifier l'intervalle de récupération

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

Si cette première requête ne renvoie pas de valeurs:

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

J'ai une assez bonne idée de ce que toutes ces valeurs représentent et comment elles fonctionnent ensemble. J'ai inclus des commentaires et des sources dans mon code ci-dessus.

Ma question est en deux parties

  1. Ma liste d'éléments/valeurs de tampon ci-dessus est-elle adéquate pour un point de départ lors de l'examen du PLE? ( c'est-à-dire des valeurs qui seront toujours utiles à considérer ensemble, si quelque chose est exclu ou inclus)

  2. Comment mettre les valeurs en contexte les unes avec les autres? ( c'est-à-dire qu'il y a un bon répondez ici en disant "Vérifiez également la valeur Free List Stalls/sec. Si au-dessus de 2, envisagez d'ajouter de la mémoire au serveur" tandis que le corps de la réponse est utile, je ne pense pas qu'une valeur de 2 pour 'Free List Stalls/sec' soit un problème dans la plupart des cas)

REMARQUE: cette question ne porte pas sur la résolution du problème de PLE, mais sur la façon/où commencer à chercher lors de l'évaluation des symptômes. Votre médecin vérifie vos pules, votre tension artérielle, vos respirations et votre température au début de chaque examen.

Modifier 13/04/2018; Tentative de clarification Il ne s'agit pas de réactions instinctives comme la vérification des index ou des attentes. Il s'agit d'identifier d'autres données de performances SQL natives qui doivent toujours être examinées avec PLE. Le PLE est l'un des objets de gestion de mémoire tampon, quels autres objets de gestion de mémoire tampon ou compteurs de performances devraient ou ne devraient pas toujours faire partie des requêtes lorsque vous voulez vraiment examiner la gestion de mémoire tampon?

sql-serverperformance
7
James Jenkins

Vous avez essentiellement demandé: "Que dois-je faire lorsque l'espérance de vie de la page change?"

Ma réponse: rien. Je ne commence pas par regarder l'espérance de vie de la page. Cette mesure était logique dans les jours 7/2000 de SQL Server, alors que c'était tout ce que nous avions, mais aujourd'hui, en 2018, nous pouvons faire mieux.

Commencez par regarder les statistiques d'attente - qui vous indiquent ce que SQL Server attend.

Peu m'importe que PLE soit 300 ou 3 000 - dites-moi sur quoi vous ATTENDEZ, SQL Server, puis je vais dépanner cette métrique.

Ma façon préférée de vérifier les attentes est d'utiliser l'open source sp_BlitzFirst (avertissement: je l'ai écrit.) Par défaut, cela prend un échantillon de 5 secondes des métriques de votre serveur et vous donne quelques suppositions comme pourquoi il est lent en ce moment.

Parce que vous aimez écrire de longues questions, vous aimerez probablement aussi celles-ci:

sp_BlitzFirst @SinceStartup = 1;

Le premier jeu de résultats vous donne vos attentes depuis le démarrage et:

sp_Blitz @ExpertMode = 1, @Seconds = 60;

Prend un échantillon plus long et indique vos attentes sur cette plage de temps.

Les statistiques d'attente peuvent être un peu cryptiques, donc à côté de chaque type d'attente, je fais un lien vers le référentiel de statistiques d'attente SQLskills pour ce type d'attente. Vous pouvez simplement copier/coller le nom de votre type d'attente supérieur, aller sur leur site et en savoir plus sur les causes de cette attente et comment y remédier.

Si PLE est en baisse en raison de requêtes lisant un grand nombre de pages de données à partir du disque, par exemple, vous pouvez voir les types d'attente PAGEIOLATCH%. S'il baisse en raison de requêtes qui reçoivent d'énormes allocations de mémoire, vous pouvez voir RESOURCE_SEMAPHORE. Si le PLE n'est pas le problème, vous verrez alors différents types d'attente.

15
Brent Ozar

Cela fait un moment que je n'ai pas posé cette question, j'ai beaucoup appris depuis.

Comme le fait remarquer Brent dans sa réponse Les alertes PLE ne vous disent rien. De par leur conception, ces pages devraient aller et venir, si elles ne restent pas longtemps lorsqu'elles ne sont plus nécessaires, c'est bien.

Néanmoins, j'ai une instance spécifique qui lance des alertes PLE plusieurs fois par jour, je l'ai regardée avec plusieurs outils, y compris le magasin de requêtes, et je ne trouve rien qui nécessite une attention. Même si j'ai ajouté de la mémoire, il ne semble pas que les alertes PLE s'arrêteraient. Je suis allé chercher un moyen de "prouver" si plus de mémoire était nécessaire ou non.

Sur les petites instances SQL avec 4 Go de RAM disponible, 75% ou 3 Go peuvent être consacrés au cache du plan. Normalement, ce n'est [~ # ~] pas [~ # ~] purgé avec les pages de données, que PLE alerte. J'ai trouvé deux façons de voir ce qui se passait avec la mémoire et le cache du plan.

Finalement, j'ai développé ( en tirant parti des liens ci-dessus) la requête ci-dessous qui montre l'espérance de vie (en minutes) des plans de cache.

    --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

Bien qu'aucun élément ne soit en soi concluant, un argument solide peut être avancé que si la durée de vie moyenne des plans dans le cache est plus longue que, le temps entre les requêtes étant réexécutées, aucune mémoire supplémentaire n'est nécessaire. L'heure spécifique sera très par cas d'utilisation.

Il y a beaucoup de raisons pour lesquelles les plans sont recompilés, voir connexes Pourquoi Query Store manque-t-il de détails? Au début, je me suis beaucoup concentré sur la recompilation élevée avec PLE, et je n'ai pas trouvé de corrélation utile.

TL: DR La mémoire est destinée à faire bouger les choses, un PLE faible n'est pas un problème. [~ # ~] mais [~ # ~] par conception, les plans utilisés doivent souvent rester en mémoire suffisamment longtemps pour être réutilisés. Si vous pouvez montrer que les plans restent en mémoire suffisamment longtemps pour être réutilisés, il est difficile de justifier l'ajout de mémoire sans autre indicateur.

1
James Jenkins