☰

证明内存升级是合理的，请看第 2 部分

tag-icon • tag-icon windows-server-2003 sql-server performance-monitoring 64-bit
证明内存升级是合理的，请看第 2 部分

之前我问过问题我应该测量哪些指标（例如之前和之后）来证明内存升级的合理性。建议使用 Perfmon。

我想知道哪一个具体的我应该测量 perfmon 计数器。到目前为止，我得到了：

PhysicalDisk/Avg. Disk Queue Length (for each drive)
PhysicalDisk/Avg. Disk Write Queue Length (for each drive)
PhysicalDisk/Avg. Disk Read Queue Length (for each drive)
Processor/Processor Time%
SQLServer:BufferManager/Buffer cache hit ratio

我还应该使用什么？

答案1

首先我建议你读一下我的关于Windows内存如何工作的答案。之后我们来谈谈计数器。从纯性能监控的角度来看，服务器内存和 SQL Server 性能无关，主要是因为 SQL Server（如果设置正确）使用锁定内存页面的功能来覆盖默认的 Windows 内存管理方案。仅从内存来看，前面提到的计数器是可以的：

SQL 内存管理器：内存授予待定

SQL 缓冲区管理器：页面寿命

SQL Server 缓冲区管理器对象：缓冲区缓存命中率

我还要补充一点

SQLServer：内存管理器：服务器总内存（KB）——这显示了 SQL Server 正在管理多少内存。

SQLServer：内存管理器：目标服务器内存（KB） - 根据 SQL Server 首次启动时保留的缓冲区数量，显示 SQL Server 认为它希望拥有多少内存。如果总数小于目标，则额外的 RAM 不太可能有帮助。如果目标大于可能受益于更多内存。

另请参阅应监控 SQL Server 的基线性能。

答案2

这些可能不是最好的计数器。磁盘 I/O 的问题在于它不会那么有用，因为除非整个数据库都在内存中，否则磁盘 I/O 在很大程度上取决于数据库优化。表扫描和报告/加载脚本等操作会使内存过载。无论内存如何，繁重的 I/O 负载都会在日志文件上产生 I/O。

这些磁盘计数器对于磁盘分析来说也不是最好的 - 队列长度并不总是很清楚，因为它会根据硬件布局而变化。例如，对于您的磁盘来说，250 可能不是一个糟糕的队列长度，但如果您有一个可以处理大量并行请求的大型 SAN，那么可能就不是了。

我更愿意选择主要因素：磁盘过载、I/O 耗时更长、秒/读取、秒/线路 - 这些都不是主观的。更多主要数据（例如秒/读取）会给出一个不依赖于硬件的唯一数字，而较低的响应时间则表明您真正想要的是什么。

为了记忆，我会采取以下做法：

  • SQL 内存管理器：内存授予待定
  • SQL 缓冲区管理器：页面寿命

最后一项让您了解页面再次退出的速度有多快。不过，您必须确保没有人强制执行此操作 - 表扫描非常适合这种情况（因为基本上，除非整个表都适合内存，否则表扫描会使缓存过载）。

相关内容