页面预期寿命 (PLE)，从哪里开始？

Question

我继承了 SQL 服务器 { 2012 (SP3)，但是这个问题是通用的} 我们使用 SCOM 来监视它。以前，我每个月收到一两次 PLE < 300 的警报。现在我有时一天会收到 2 或 3 条警报。

有很多关于 PLE 的博客文章，一些你可以用来监控它的工具，以及关于什么是好的、坏的或无所谓的许多不同的意见。最后有很多变数。没有任何解决方案是一刀切的。低 PLE 与其说是一种症状，不如说是一个问题，它有很多潜在的原因，以及需要考虑的相关措施。

{这一段可能不会增加问题的价值，我愿意删除它} 我想每个人都同意在隔夜报告创建期间 PLE 每月一次下降到 299，是一种不需要解决的症状（假设报告在营业时间之前完成）。大多数人也同意 PLE 一直保持在 350 是不好的。在进行硬件更改之前，有几个原因需要考虑，查询和索引接近顶部。

在阅读了大约 12 篇关于 PLE 的博客文章后。我试图缩小关键症状的范围，以便对正在发生的事情有一个很好的了解。下面的查询是我想出的。它给出了与 PLE 互连的 4 个缓冲区管理器项的值

• '页面预期寿命'
• '空闲列表摊位/秒'
• '懒惰写入/秒'
• '缓冲区缓存命中率'

...

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

此外，如果您正在查看继承服务器上的延迟写入，您应该检查恢复间隔

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

如果第一个查询没有返回值：

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

我非常清楚所有这些值代表什么，以及它们如何协同工作。我在上面的代码中包含了注释和来源。

我的问题是两部分

1. 在检查 PLE 时，我的缓冲区项目/值列表是否足以作为起点？（即，如果排除或包含某些内容，将总是有助于一起考虑的值）

2. 如何将价值观置于良好的环境中？（即这里有一个很好的答案，说“也检查空闲列表停顿/秒值。如果高于 2，请考虑向服务器添加内存”，而答案的正文很有帮助，我不认为值为 2对于“免费列表摊位/秒”在大多数情况下是一个问题）

注意：这个问题不是关于解决 PLE 问题，而是关于在评估症状时如何/从哪里开始寻找。您的医生会在每次检查开始时检查您的脉搏、血压、呼吸和体温。

2018 年 4 月 13 日编辑；尝试澄清 这与检查索引或等待等下意识反应无关。这是关于识别应始终使用 PLE 检查的其他本机 SQL 性能数据。PLE 是缓冲区管理对象之一，当您确实想要查看缓冲区管理时，哪些其他缓冲区管理对象或性能计数器应该或不应该始终作为查询的一部分？

Answer 1

您基本上会问，“当页面预期寿命发生变化时我该怎么办？”

我的回答是：没什么。我不是从查看页面预期寿命开始的。这个指标在 SQL Server 7/2000 天是有意义的，当时我们拥有一切，但今天，在 2018 年，我们可以做得更好。

首先查看等待统计信息 - 它告诉您 SQL Server 正在等待什么。

我不在乎 PLE 是 300 还是 3,000——告诉我你在等待什么，SQL Server，然后我会去解决那个指标的问题。

我个人最喜欢的检查等待的方法是使用开源sp_BlitzFirst（免责声明：我编写了它。）默认情况下，它需要 5 秒的服务器指标样本，并让您猜测为什么它现在很慢。

因为你喜欢写长问题，你可能还会喜欢这些：

sp_BlitzFirst @SinceStartup = 1;

第一个结果集为您提供自启动以来的等待时间，以及：

sp_Blitz @ExpertMode = 1, @Seconds = 60;

获取更长的样本，并告诉您在该时间范围内的等待时间。

等待统计数据可能有点神秘，所以在每个等待类型旁边，我链接到该等待类型的SQLskills 等待统计信息存储库。您只需复制/粘贴您的主要等待类型的名称，访问他们的网站，并了解更多关于导致等待的原因以及如何解决它的信息。

例如，如果 PLE 因查询从磁盘读取大量数据页而下降，您可能会看到 PAGEIOLATCH% 等待类型。如果由于查询获得大量内存授权而下降，您可能会看到 RESOURCE_SEMAPHORE。如果 PLE 不是问题，那么您将看到完全不同的等待类型。