如何使用 t-sql 提取 perfmon 计数器“内存：页/秒”？

Question

我已经用谷歌搜索过这个，到目前为止，没有运气，所以向所有伟大的专家寻求帮助。

我试图弄清楚是否有办法使用 t-sql 获取性能计数器“内存：页/秒”，因为我试图将其添加为我们的 Ignite 监控工具中的自定义指标。我查看了 sys.dm_os_performance_counters DMV 但没有在那里找到它。

有人知道这样做的方法吗？提前致谢 ：）

Answer 1

理想情况下/从长远来看，我确实同意@Aaron（对问题的评论）关于联系 SolarWinds 请求他们为此创建自定义指标的观点。但即使你这样做并且他们接受了这个想法，他们也可能需要一段时间才能发布它。同时，或者如果您只是想以临时方式查看此信息，您可以尝试以下操作：

如果该指标确实与报告的“页面错误”指标相同DBCC MEMORYSTATUS ^{（请参阅底部的注释}） ，那么您可以执行以下操作：

DECLARE @BeginningValue TABLE
(
  [Counter] NVARCHAR(100) NOT NULL,
  [Value] BIGINT NOT NULL,
  [InsertTime] DATETIME NOT NULL DEFAULT (GETDATE())
);
DECLARE @EndingValue TABLE
(
  [Counter] NVARCHAR(100) NOT NULL,
  [Value] BIGINT NOT NULL,
  [InsertTime] DATETIME NOT NULL DEFAULT (GETDATE())
);
---

INSERT INTO @BeginningValue ([Counter], [Value])
  EXEC ('DBCC MEMORYSTATUS;');

WAITFOR DELAY '00:00:10.000'; -- 10 second pause

INSERT INTO @EndingValue ([Counter], [Value])
  EXEC ('DBCC MEMORYSTATUS;');
---

DELETE FROM @BeginningValue WHERE [Counter] <> N'Page Faults';
DELETE FROM @EndingValue WHERE [Counter] <> N'Page Faults';

SELECT lst.Value AS [EndingValue], frst.Value AS [BeginningValue],
       lst.InsertTime AS [EndingTime], frst.InsertTime AS [BeginningTime],
       (lst.Value - frst.Value) AS [Difference],
       DATEDIFF(SECOND, frst.InsertTime, lst.InsertTime) AS [NumSeconds],
       CONVERT(DECIMAL(14, 4),
               (((lst.Value - frst.Value) * 1.0) /
                        DATEDIFF(SECOND, frst.InsertTime, lst.InsertTime))
              ) AS [PageFaults/Sec]
FROM   @BeginningValue frst
CROSS JOIN @EndingValue lst;

返回：

Ending  Beginning  EndingTime               BeginningTime            Diff  Sec.  Faults/Sec
418529  418497     2016-01-28 13:13:27.850  2016-01-28 13:13:17.827  32    10    3.2000

笔记

• 如果您使用的是 SQL Server 2008 或更高版本，请使用sys.dm_os_process_memory DMV（如 @Aaron 的回答中指出的），否则您可以DBCC MEMORYSTATUS按照我上面所示的方式使用。DBCC MEMORYSTATUS由于忽略了从任何 DMV 返回的字段，我只推荐了（因此这种捕获其返回信息的方法）。DBCC MEMORYSTATUS但我已经对它们进行了测试，并且它们返回相同的值，因此，如果您有权访问 DMV，则考虑到所需的额外工作，实际上没有充分的理由使用它们sys.dm_os_process_memory。

• 我在最初发布这个答案时没有详细说明这一点，但样本之间的 10 秒实际上相当短，并且可能会降低结果指标的准确性。理想情况下，会使用更大的数字——至少 30 秒（如果不是 60 秒）。然而，令人担忧的是，让监视工具调用此代码（我假设它将被放入存储过程中）会在监视软件中引入潜在风险，考虑到延迟是超时，或者以某种方式延迟其处理或收集其他信息指标。因此，我使用 10 秒作为一种更注重可靠性而不是准确性的方法。这可以追溯到我一开始所说的同意@Aaron 的理想场景立场，即软件供应商提供收集此信息的本机/内置方法。