页面查找百分比 - SQL Server 性能监控

Question

我目前正在做一些监控 SQL Server 性能的工作。我发现以下脚本 [1] 计算“页面查找百分比” - 建议是“好”值小于 100。

SELECT 1.0*cntr_value /
(SELECT 1.0*cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Batch Requests/sec') 
AS [PageLookupPct]
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Page lookups/sec'

现在我已经在大约十几个不同的服务器上运行了这个脚本——大部分是虚拟的，但有几个物理的，主要是 2008R2 Enterprise，但有几个 2005，一些是实时的，一些是开发的，甚至是一个物理的 2008R2 Express 版本，它只是一个见证服务器并且当前处于休眠状态（没有设置镜像以进行主动故障转移）。只有其中一台服务器的值低于 100。在大多数情况下，它一直在 1000 左右，或者至少在 100 左右。在休眠的见证服务器上，价值是荒谬的 20,000 ！

这是否表明我们在这方面存在广泛的问题，或者对于为什么在这么多不同的服务器上这个数字应该如此之高，是否有一些无辜的解释？我们在其中一些服务器上遇到了性能缓慢的问题，因此更好地了解这个数字告诉我的内容对我很有用。

[1] - http://thomaslarock.com/2012/05/are-you-using-the-right-sql-server-performance-metrics/

Answer 1

该指标试图衡量每个请求执行的逻辑 IO 操作的平均数量。如果您的服务器是，比方说，为一个繁忙的网站提供服务，那么这可能是一个很好的指标（也许 100 甚至太高了！）。

见证人将只有内部活动。换句话说，尽管从未看到任何实际批次，但由于各种后台进程，它会在内部接触数据文件。因此，所有内部逻辑 IO 都将报告为由该服务器所看到的少数批次引起的。

我想说的是 Thomas 推荐的指标具有一定的价值，但仅适用于与 Thomas 所想的类似的工作负载。一个只有后台活动的服务器，比如你的见证人，不会报告任何有意义的这个比率。运行密集型 DW 报告的服务器可能每小时只能看到 1 个批处理请求，并为该请求运行数百万次页面查找。如果您的工作负载具有足够频繁的批处理请求以建立重要的统计趋势，并且每个批处理请求预计平均执行低于 100 页的查找，则像“必须低于 100”这样的绝对数字只有伴随小字体免责声明才有价值，例如必须低于 100。你明白了...