Page Life Expectancy 对该实例有何看法？

Question

我已经在环境中的几个 SQL Server 实例上安装了监控软件。我试图找到瓶颈并解决一些性能问题。我想知道某些服务器是否需要更多内存。

我对一个计数器感兴趣：页面预期寿命。在每台机器上看起来都不一样。为什么在某些情况下它会经常更改，这意味着什么？

请查看上周在几台不同机器上收集的数据。你能对每个实例说些什么？

大量使用的生产实例（1）：

适度使用的生产环境 (2)

很少使用的测试实例（3）

大量使用的生产实例 (4)

适度使用的测试实例（5）

大量使用的数据仓库 (6)

编辑：我为所有这些服务器添加了 SELECT @@VERSION 的输出：

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)

我还在机器上运行了以下查询：

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

它为每个服务器返回 2 或 3 行：

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

这是什么意思？这些服务器是否运行 NUMA？

Answer 1

摘自 MSDN：- https://msdn.microsoft.com/en-us/library/ms189628.aspx

页面预期寿命 - 表示页面在没有引用的情况下将在缓冲池中停留的秒数。

SQL 总是在内存中查找数据页。如果数据页不在内存中，SQL 将不得不转到磁盘（执行物理 IO 操作）以检索满足请求所需的数据。如果您的 PLE 计数器较低，则表明内存中的数据页经常被来自物理 IO 操作的新页覆盖。物理 IO 操作代价高昂，这意味着您的 SQL 实例的性能将受到不利影响。因此，您会希望 PLE 计数器尽可能高。

忽略您在网上看到的任何提及 300 作为此计数器的良好阈值的建议

这个阈值来自内存有限的日子（想想 32 位系统）。现在我们有 64 位系统，它可以有 TB 的 RAM，所以这个建议已经过时了。

首先，您是否限制了 SQL 的内存？如果是这样，还剩下多少可用内存？可以提高限额吗？

我会在您的服务器上寻找的第二件事是，是否有任何维护工作在运行？检查执行索引重建、更新统计或 DBCC CHECKDB 操作的作业。这些执行大量读取，可能是您的 PLE 扁平衬里的原因，

接下来，当您使用 SQL Server 2008+ 时，您可以设置一个扩展事件会话来捕获执行大量读取的查询。这是这样做的代码：-

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

这将捕获服务器上执行超过 200000 次逻辑读取的所有查询。我不知道您在每台服务器上有多少内存，因此您可能需要调整该数字。创建完成后，您可以通过运行以下命令启动会话：-

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

然后通过运行查询会话：-

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

运行这个时要小心！该文件可能会变得非常大，因此请先在开发实例上对其进行测试。您可以设置最大值。文件的大小，但我没有包括在这里。这是扩展事件的 MSDN 链接：- https://msdn.microsoft.com/en-us/library/hh213147.aspx

定期监视此会话，并希望它可以接收到您的 PLE 中出现的任何疑问。

进一步阅读——

PLE 上的 MSDN 博客 - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx

关于设置扩展事件的视频 - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ （来自我自己的博客，对无耻的自我宣传感到抱歉)

Answer 2

页面预期寿命是衡量刚刚从磁盘读取的页面在被其他内容推出或被销毁之前可以在内存中停留多长时间的指标（即，该页面在磁盘上被释放，不再需要使用）。以将副本缓存在 RAM 中）。

作为一般衡量标准，它越高，处理负载模式的速度就越快，因为事物都保存在内存中。如果它非常低，则可能表明由于内存不足而导致性能问题。

读数低并不总是意味着存在问题：例如，在大量一次性进程使用大量页面之后，读数可能会很低，因此将它们引入并删除以腾出更多空间。例如，您的图表在每天结束时似乎会下降，这可能是由夜间管理工作（备份、数据归档、其他夜间处理）引起的。