文章/答案/技术大牛

发布

社区首页 >问答首页 >预期寿命(PLE)，从哪里开始？

问预期寿命(PLE)，从哪里开始？
EN

Database Administration用户

提问于 2018-04-12 17:16:12

回答 2查看 16.6K关注 0票数 8

我继承了一个SQL server {2012 (SP3)，但是这个问题是泛型的}我们正在使用SCOM来监视它。以前我每个月都会收到一两次关于PLE < 300的警告。现在我一天有两三次机会。

有多篇关于PLE的博客文章，你可以得到一些工具来监控它，对于什么是好的，什么是坏的或者什么是无动于衷的，有许多不同的观点。最后，有很多变量。没有任何解决办法是一刀切的。低PLE与其说是一个问题，不如说它是一种症状，有许多潜在的原因，以及相关的措施需要考虑。

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

在阅读了十几篇关于PLE的博文之后。我试图缩小关键症状范围，以便更好地了解正在发生的事情。下面的查询是我想出的。它给出了与PLE互连的4个缓冲区管理器项的值

“预期寿命”
“自由列表暂停/秒”
“懒散写/秒”
‘缓冲缓存命中率’

..。

SELECT [object_name],
[counter_name],
[cntr_value] FROM sys.dm_os_performance_counters -- https://learn.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://learn.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];

此外，如果您正在查看继承服务器上的Lazy写操作，则应检查恢复间隔。

EXEC sp_configure @configname='recovery interval (min)';  --The  'config_value' default 0 indicates SQL is applying Checkpoints completely automatically https://learn.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://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-performance-counters-transact-sql

我很清楚所有这些价值观代表着什么，以及它们是如何一起工作的。我在上面的代码中包含了评论和来源。

我的问题是

的两部分

当检查PLE时，我上面的缓冲区项目/值列表是否足以作为起点？(即在排除或包括的情况下，总是有助于共同考虑的价值观)
如何将这些价值观放在良好的上下文中？(即有一个好的在此回答：“也检查空闲列表/秒值。如果以上2，请考虑向服务器添加内存”。，而答案的主体是有用的，我不认为‘空闲列表暂停/秒’的值2在大多数情况下是一个问题)

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

编辑4/13/2018；试图澄清这与膝跳反应无关，比如检查索引或等待。这是关于标识其他应该始终使用PLE检查的原生SQL性能数据。PLE是缓冲区管理对象之一，当您真正想要查看缓冲区管理时，哪些其他缓冲区管理对象或性能计数器应该或不应该始终是查询的一部分？

sql-server

performance

回答 2

Database Administration用户

发布于 2018-04-12 17:25:18

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

我的回答是:没什么。我不是从看佩奇的预期寿命开始。这个指标在Server 7/2000天里是有意义的，当时我们只有这些，但现在，在2018年，我们可以做得更好。

首先查看等待状态--这将告诉您Server在等待什么。

我不在乎PLE是300还是3,000 --告诉我您在等待什么，Server，然后我将对这个度量进行故障排除。

我个人最喜欢的检查等待的方法是使用开源服务提供商_BlitzFirst (免责声明:我写的)。默认情况下，它需要一个5秒钟的服务器度量样本，并给您一些猜测为什么它现在慢。

因为你喜欢写冗长的问题，你可能也会喜欢以下几个问题：

sp_BlitzFirst @SinceStartup = 1;

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

sp_Blitz @ExpertMode = 1, @Seconds = 60;

需要一个较长的样本，并告诉您等待的时间范围。

等待状态可能有点神秘，所以在每种等待类型的旁边，我都链接到该等待类型的SQLskills等待状态存储库。您只需复制/粘贴您的顶部等待类型的名称，转到他们的网站，并了解更多的原因，以及如何解决它。

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

票数 15

Database Administration用户

发布于 2019-05-30 15:01:00

我问这个问题已经有一段时间了，从那以后我学到了很多东西。

正如布伦特在他的回答中指出的那样，PLE警报本身并不能真正告诉你任何事情。从设计上看，这些页面应该来来去去，如果它们在不再需要的时候不再停留很久，那就好了。

尽管如此，我有一个特定的实例每天都会多次抛出PLE警报，我一直在使用包括查询存储在内的几个工具来查看它，而没有发现任何需要注意的东西。即使我添加了内存，看起来PLE警报也不会停止。我去寻找一种方法来“证明”是否需要更多的记忆。

在具有4GB可用RAM的小型SQL实例上，75%或3GB可用于计划缓存。通常情况下，这不是清除与数据页，PLE警报。我找到了几种方法来查看内存和计划缓存发生了什么。

最后，我开发了(利用上面的链接)下面的查询，它显示缓存计划的预期寿命(分钟)。

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

虽然没有一个项目本身是决定性的，但可以提出一个强有力的论点，即如果计划在缓存中的平均寿命比运行查询之间的时间长，则不需要额外的内存。具体的时间将非常用例。

有很多原因使计划被重新编译，见相关的查询商店为什么缺少详细信息？早期，我集中在高重新编译与PLE，而没有找到一个有用的相关性。

TL:DR记忆的目的是让事物来来去去，低PLE并不是问题。但从设计上看，经常使用的计划应该在内存中保留足够长的时间，以便重新使用。如果您可以证明计划在内存中停留的时间足够长，可以重用，那么在没有其他指示符的情况下，很难证明添加内存是合理的。

票数 1

页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持

原文链接：

https://dba.stackexchange.com/questions/203784

复制

相似问题

问预期寿命(PLE)，从哪里开始？
EN

我的问题是

回答 2

Database Administration用户

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

Database Administration用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问预期寿命(PLE)，从哪里开始？EN

我的问题是

回答 2

Database Administration用户

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

Database Administration用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问预期寿命(PLE)，从哪里开始？
EN