逐渐增加的交换使用量是否是内存泄漏的指标？

Question

I\xe2\x80\x99m 试图了解我的服务器（Windows Server 2012R2）上是否存在内存泄漏。该服务器具有 48 GB RAM，设计用于仅运行 DBMS（SQL Server 2014），但还安装了其他工具，如 Symantec Endpoint Protection、FireEye 和一些监控工具/服务。当前配置为为 DBMS 保留 42 GB，为操作系统和其他服务保留 6 GB。当只为操作系统和其他服务保留 4 GB 时，会出现内存不足错误，在我将其增加到 6 GB 后，该错误消失了。对于 SQL Server 计算机来说，高 RAM 使用率本身是正常的，因为 SQL Server 在 RAM 中缓冲数据。

\n

让我担心的是，交换使用量（性能计数器分页文件 -> 使用情况）在过去 2 个月中逐渐增加，目前达到 24 GB（交换文件大小）的 15%。我\xe2\x80\x99m 不确定这是否可以，因为Windows 即使在正常情况下也会将内容放入交换区，或者它是否表明一段时间后6 GB 也将\xe2\x80\x99 不够用。下面的图表中，绿线是 RAM 使用情况（当我重新启动 SQL Server 时急剧下降，然后又迅速上升），黄线是自 5 月中旬以来的交换使用情况。

\n

交换使用图像

\n

\n

我做了什么：

\n

\n

1. 转储性能计数器 \xe2\x80\x9cProcess->Private bytes\xe2\x80\x9d。这里没什么可疑的。以 MB 为单位的 TOP10 为（总计 44711 MB）：

   \n
   \n
   • sqlserver 41322
   \n
   • xagt#5504
   \n
   • ccvchst 316
   \n
   • 斯普伦克德 285
   \n
   • ccsvchst#1 260
   \n
   • 监控主机233
   \n
   • xagt#1 151
   \n
   • 监控主机#1 129
   \n
   • 健康服务 116
   \n
   • 服务主机#4 110
   \n
   \n
\n

2. 尝试重新启动各个服务（SQL Server、xagt/Fireeye、splunkd）。这对交换使用没有影响。

   \n
\n

3. 尝试使用 Sysinternals 和 VMMap 的工具 RAMMap 获取更多信息，因为我怀疑某些进程通过内存映射文件泄漏内存，这些文件不计入私有字节。

   \n

   RAMMap 报告如下（不幸的是，文件摘要/文件详细信息下的文件总共仅使用了不到 300 MB，但映射文件的活动报告为 2659 MB）：

   \n

   rammap 的屏幕截图

   \n

   

   \n
\n

\n

我有另一台服务器，安装了相同的工具，但具有 96 GB RAM 和 16 GB 交换空间。RAM 使用率低于 50%，但交换使用率也（几乎）持续增加，目前达到 28%。

\n

在另一台服务器上交换使用情况

\n

\n

这种行为正常吗？如果没有，我如何找到有问题的进程？

\n

Answer 1

支持交换存储是一个可参考的参数。当内存足够时，就不需要过度使用内存。我之前的回答并不是真正的解释。

结论是，发布者确实存在内存泄漏，但工具中并未显示出来。这通常意味着泄漏发生在 Windows 或某些第三方驱动程序中。

此类泄漏很难发现，而且一旦发现，它们通常位于无法修改的专有代码中。

由于这种情况下的泄漏非常小，没有影响性能，所以这个问题大多只是一个烦恼。它可以通过经常重新启动来修复。对于发帖者来说，这种情况甚至可能每月一次。

先前的答案，当可用信息较少时：

您显然有这样的印象：只有当 Windows（或任何操作系统）内存不足时才会使用交换空间。事实并非如此。

当 RAM 耗尽时，操作系统必须准备好交换进程。因此，对于任何请求 RAM 的进程，操作系统都会分配与请求量相等的后备交换空间，甚至在授予 RAM 请求之前就进行分配。分配的交换空间不一定分配为特定的磁盘扇区，但操作系统将确保在需要时有足够的可用空间。

您观察到的增加意味着您的 DBMS 正在缓慢增加其内存大小并要求更多 RAM。互换相应增加。

为了完全安全，交换空间应等于 RAM 大小。您分配的 6 GB 远远不够。交换使用量的增加不应令人担忧。