进一步调查似乎表明我们已达到非分页池限制.从那时起,我们一直在使用Poolmon.exe监视非分页池内存,我们相信我们已经识别出导致问题的标记.
Tag Type Allocs Frees Diff Bytes Per Alloc Even Nonp 51,231,806 50,633,533 684,922 32,878,688 48
如果我们使用poolmon.exe / g,它会将映射的驱动程序显示为[<未知>事件对象].
这几乎没有任何帮助.我的团队花了相当多的时间研究这个问题,并且无法找到将其缩小到特定应用程序或服务的过程.我感觉大多数人似乎通过杀死机器上的进程来解决问题,直到他们看到非分页存储器重置为止.这不是您在生产机器上工作时想要看到的内容.
如果我打开任务管理器并查看进程列表.我看到MailService.exe的NP池值为105K,这比第二个列出的进程值高36K.由于过去我们的邮件服务器存在一些问题(可能与此问题有关,也可能没有),我的直觉是这导致了问题.
然而,在我们重新启动服务之前,我想要比“直觉”更有把握.
我也尝试过使用poolmon.exe / c但这总是会返回错误：
unable to load msvcr70.dll/msvcp70.dll
它不会创建localtag.txt.我的同事不得不从互联网上下载pooltag.txt,因为我们无法弄清楚它位于何处.我们没有win调试器或win DDK安装(我可以看到).也许上面的错误是因为我们没有安装这些错误 – 但我不知道.
最后我试过：
C:\windows\system32\driver\findstr /m /l Even *.sys
这返回了一个相当大的.sys文件列表,并且再次对手头的问题没有任何帮助.
所以我的问题是：有没有其他方法可以缩小内存泄漏的原因？
更新：
如下所示,我一直在记录最后一天左右的Pool Nonpaged Bytes,以查看是否有任何进程趋势.在大多数情况下,所有过程在其使用中看起来都是相当静态的.其中两个看起来略微上升.接下来的几天我会继续监控这个.
我也忘了早些时候提到,没有一个进程似乎也使用了过多的句柄.
更新2：
过去几周我一直在监视这个问题.在此期间,各个进程的非分页字节池和总非分页字节池都保持相对稳定.在此期间Windows更新并重新启动服务器,所以我想知道是否已解决问题.我现在肯定没有看到Nonpaged Bytes Pool的持续增长.
首先,单个进程的非分页字节并没有真正告诉我任何有用的东西,因为它们在使用时似乎都是相当静态的.有尖峰但后来使用总是返回到基线.
Nonpaged Bytes Memory总计也是静态的一段时间,但随后开始逐渐增加然后加标.在大约一半的内存被释放后,然后它再次保持静态(在较高级别)一段时间,直到重复模式.看着图表,我注意到这些尖峰似乎是相当规则的间隔,因为事实证明它们发生在相隔2周并且总是在星期天.
所以接下来的问题是：星期天两周运行什么？我去了一下事件查看器,每次发生尖峰时,迈克菲都在运行.我还认为通过频繁登录服务器来监控问题,我们无意中使问题变得更糟,因为迈克菲有一个实时扫描仪,我相信这导致了我们看到的较小的增长.
我认为扫描是计划任务也解释了为什么我们看到附加到PoolMon中的Event对象标签而不是McAfee特定标签的NP内存增加.这是让我们走上花园小径的主要因素.
现在我们终于知道是什么导致了泄漏,我们可以做些什么.令人难以置信的是,花了很长时间来追踪它.
更新：正如最后一点.迈克菲在周末更新,这完全解决了我们的非分页内存问题.
更新2：由于我刚刚投票,我将为此添加更新.最初对McAfee的更新确实解决了我们的问题,即我们不再定期看到NP内存中的大量峰值.我还注意到,自更新以来,McAfee现在默认不再将日志写入事件查看器,这在主动扫描时会隐藏.
但我们仍然看到NP内存使用量逐渐增加.它已经到了我们现在需要每两周左右重新启动服务器的程度.这是非常糟糕的,我们最近购买了一台新的服务器,希望更新的硬件和软件能够解决这个问题但是我们全新的服务器只安装了Windows Server 2008,sql Server 2008 R2和McAfee,而STILL则显示NP内存泄漏.只有在我完全删除McAfee之后,泄漏才停止,即使我们使用我们所有的软件设置服务器以准备切换到它,它仍然保持静止.
我已经读过了,我不知道这是不是真的,问题不在迈克菲,而是迈克菲使用的一些Windows例程导致NP内存泄漏.显然,网络活动是泄漏的原因,即更多的网络活动=>更大的泄漏.这似乎与我们的经验一致,因为我们的服务器变得更加繁忙,泄漏变得更糟.
