如何确定哪个应用程序正在泄漏非分页内存?

Dev*_*per 8 windows-server-2003 poolmon

我们最近在我们的实时服务器上遇到了一个问题,导致我们的 Web 应用程序停止响应。我们得到的只是 503 错误,直到我们重新启动服务器,然后一切正常。最终我追溯到 httperr.log 并发现了一大堆 1_Connections_Refused 错误。

进一步调查似乎表明我们已达到非分页池限制。从那时起,我们一直使用 Poolmon.exe 监视非分页池内存,我们相信我们已经确定了导致问​​题的标签。

Tag   Type    Allocs       Frees       Diff       Bytes      Per Alloc
Even  Nonp  51,231,806   50,633,533   684,922   32,878,688      48
Run Code Online (Sandbox Code Playgroud)

如果我们使用 poolmon.exe /g,它会将映射驱动程序显示为 [< 未知 > 事件对象]。

这几乎没有任何帮助。我的团队花了大量时间研究这个问题,但一直没能找到一个过程来将这个问题缩小到特定的应用程序或服务。我觉得大多数人似乎通过杀死机器上的进程来解决问题,直到他们看到非分页内存重置。这不是您在生产机器上工作时想要看到的。

如果我打开任务管理器并查看进程列表。我看到 MailService.exe 的 NP Pool 值为 105K,这比列出的第二个进程的值高 36K。由于过去我们的邮件服务器出现了一些问题(可能与此问题有关,也可能无关),我的直觉是这是导致问题的原因。

但是,在我们开始重新启动服务之前,我希望有更多的确定性,而不仅仅是“直觉”。

我也试过使用 poolmon.exe /c 但这总是返回错误:

unable to load msvcr70.dll/msvcp70.dll
Run Code Online (Sandbox Code Playgroud)

它不会创建 localtag.txt。我的同事不得不从互联网上下载 pooltag.txt,因为我们无法弄清楚它的位置。我们没有安装 win 调试器或 win DDK(我可以看到)。也许上述错误是因为我们没有安装其中任何一个 - 但我不知道。

最后我试过:

C:\windows\system32\driver\findstr /m /l Even *.sys
Run Code Online (Sandbox Code Playgroud)

这返回了相当大的 .sys 文件列表,再次对手头的问题没有任何帮助。

所以我的问题是:有没有其他方法可以缩小这种内存泄漏的原因?

更新:

如下所示,我一直在记录最后一天左右的池非分页字节数,以查看是否有任何进程呈上升趋势。在大多数情况下,所有进程的使用似乎都是相当静态的。其中两个看起来略有上升。在接下来的几天里,我将继续关注这一点。

我之前也忘了提到,似乎没有一个进程使用过多的句柄。

更新 2:

在过去的几周里,我一直在监视这一点。在此期间,各个进程的非分页字节池和总非分页字节池都保持相对稳定。在此期间,Windows 已更新且服务器重新启动,因此我想知道是否已解决问题。在此之前,我绝对没有看到非分页字节池的持续增长。

Dev*_*per 6

我已经对此进行了大约 6-7 周的监控,最终可以对问题给出明确的答案。

首先,各个进程的非分页字节并没有真正告诉我任何有用的信息,因为它们在使用中似乎都是相当静态的。有峰值,但之后使用总是回到基线。

Nonpaged Bytes Memory 总数也有一段时间是静态的,但随后开始逐渐增加,然后飙升。在一个峰值之后,大约一半的内存被释放,然后它再次保持静态(在更高级别)一段时间,直到模式重复。查看图表,我注意到这些尖峰似乎相当有规律地间隔开,结果它们相隔 2 周发生,并且总是在星期天发生。

所以下一个问题是:星期天每两周播出什么节目?我去事件查看器中查看,每次出现峰值时,McAfee 都在运行。我还认为,通过频繁登录服务器来监控问题,我们无意中使问题变得更糟,因为 McAfee 有一个实时扫描程序,我相信这导致了我们看到的较小的增长。

我认为扫描是计划任务也解释了为什么我们看到 NP 内存增加附加到 PoolMon 中的事件对象标签而不是 McAfee 特定标签。这是真正引导我们走上花园小径的主要因素。

现在我们终于知道是什么导致了泄漏,我们可以做些什么了。令人难以置信的是,花了这么长时间才找到它。

更新:就像最后一点。McAfee 在周末进行了更新,这完全解决了我们的非分页内存问题。

更新 2:由于我刚刚对此投了赞成票,因此我将为此添加进一步的更新。最初,McAfee 的更新似乎确实解决了我们的问题,即我们不再看到 NP 内存中定期出现的大量峰值。我还注意到,自更新以来,McAfee 现在似乎不再默认将日志写入事件查看器,它在主动扫描时隐藏。

但是我们仍然看到 NP 内存使用量逐渐增加。现在已经到了需要每两周左右重新启动服务器的地步。很糟糕,我们最近购买了一台新服务器,希望更新的硬件和软件能够解决这个问题,我们仅安装了 Windows Server 2008、SQL Server 2008 R2 和 McAfee 的全新服务器仍然显示 NP 内存泄漏. 只有在我完全删除 McAfee 之后,泄漏才停止,并且即使在我们使用所有软件设置服务器以准备切换到它之后,泄漏仍然保持不变。

我已经读过,我不知道这是否属实,问题不在于 McAfee,而是 McAfee 使用的某些 Windows 例程会导致 NP 内存泄漏。显然,网络活动是泄漏的原因,即更多的网络活动 => 更大的泄漏。这似乎与我们的经验一致,因为随着我们的服务器变得更加繁忙,泄漏变得更糟。