为什么资源监视器和任务管理器的总 RAM 使用量甚至远远达不到总物理内存使用量?

为什么资源监视器和任务管理器的总 RAM 使用量甚至远远达不到总物理内存使用量?

我在许多不同的 Windows 机器上多次注意到了这一点:任务管理器或资源监视器报告的 RAM 使用量似乎经常加起来达到显著地低于实际使用量。

例如,我多次在笔记本电脑或台式机上看到使用量约为 7GB,但工作 RAM 集的总量却只有 3GB。我就是搞不清楚它用在哪儿了!

这是我今天在服务器资源监视器中注意到的一个极端示例:

资源监控
点击查看完整尺寸

如果您右键单击该图像并在新选项卡中打开并查看数字,您会注意到工作集(不包括非物理虚拟内存)总计约为 1.7GB。当启用“显示所有用户的进程”时,我在任务管理器中将 RAM 使用量相加,得到了类似的数字。

以下是任务管理器“性能”选项卡的屏幕截图:

任务管理器
点击查看完整尺寸

这说明有 7.6GB 的物理内存正在使用中。

我在个人电脑、笔记本电脑以及现在的服务器上经常看到这种情况:系统工具报告的总 RAM 使用量仅占我观察到的 RAM 使用量的 1/4 左右。到底发生什么事了???

有没有令人满意的解释可以说明我的 RAM 都去哪儿了?什么东西占用了这些 RAM,为什么没有留下任何痕迹?

编辑:这是用户 whs 要求的图形 RAM 使用情况的图片:

RamMap 使用
点击查看完整尺寸

编辑2:为了回应詹姆斯的回应,这里有一张非分页进程的图片poolmon.exe,按大小排序:

在此处输入图片描述

这些结果让我感到困惑。poolmon正确指出我正在使用 6GB 的非分页池,但所有非分页池进程的大小都小于 8MB。

这是什么意思?是否poolmon无法检测到某些使用非分页池的进程?

答案1

对不起,我知道这听起来像是一个轻率的回答......但你标题中问题的答案是“因为他们不应该这样做”。

或者更礼貌地说:很多 RAM 的使用并不在进程的私有工作集中。其中一些在进程的共享工作集中 - 但由于共享,您无法获得那里实际使用情况的可靠概念;将进程的数量相加将得到过大的结果。

占用 RAM 的其他内容,例如非分页池、分页池的常驻部分以及其他内核空间用途的常驻部分,根本不会出现在任务管理器的“进程”显示中。

关于您的具体问题:

在任务管理器屏幕上,看到“内核内存”部分了吗?您有 6 GB 的“非分页内存”(即非分页池)。这是第二张图中“正在使用”部分的一部分。非分页池不分配给任何进程,这就是为什么任务管理器中每个进程的数字相加不会接近总使用量的原因。某些驱动程序很可能正在使用它。这是一个完全过量的数量;它应该远低于 1 GB。无论哪个驱动程序对非分页池使用量的过量负责,毫无疑问都是有缺陷的。

RAMmap 可以确认这一点(在其“使用计数”选项卡上,查看“非分页池”的总数),但它无法帮助您找到导致此问题的驱动程序。

找到它的方法如下:获取 Microsoft 工具“poolmon”的副本。它是随 Windows 驱动程序工具包一起分发的字符模式工具(天哪,它真是个好东西)。对于 Windows 7,WDK 是一个免费下载。您必须下载整个文件(它是一个 ISO)并从中安装,但如果您只需要安装工具,您也可以选择只安装工具。

在 WDK 目录中找到 poolmon - 确保选择正确的 32 位或 64 位 - 并从管理员命令提示符运行它。您将看到如下显示:

在此处输入图片描述

现在,按“p”键(不,我不是在开玩笑。这里没有菜单!)直到“Type”列仅显示“Nonp”。然后按“b”(如果需要,按两次)按字节列的降序对显示进行排序(此处的示例中已经完成了)。

然后查看最上面一行的“标记”列。在这里显示的(显然是人为的)情况下,它是“泄漏”。(此系统正在运行一个故意出错的驱动程序,导致此问题 - 它正在“泄漏”非分页池。)

顺便说一句,突出显示的行是自上次更新这个过时的屏幕以来发生变化的行。

现在在 c:\Windows\System32\Drivers 中搜索包含该字符串的 .sys 文件。在本例中,您需要查找“Leak”,如下所示:

c:\windows\system32> findstr /s Leak *.sys

然后在网上搜索对该字符串和/或该驱动程序名称的引用。

返回此处并报告 .sys 文件中的全名、制造商名称等也会有所帮助。

(我敢打赌,你找到的标签是 ECMC,驱动程序是 intmsd.sys,并且它与名为 ExpressCache 或 IntelliMemory 的产品相关联。我会“卸载”该产品。有一个更新可以修复该问题,但即使使用修复版本,我也从未见过该产品可以提高系统性能;它基本上复制了 Windows 中已有的功能。)

如果用这种方法找不到,下一步是使用“Windows Performance Toolkit”。在本论坛中搜索该字符串,查看 magicandre1981 的回答,了解操作方法。忽略提到 xperf 的回答 - 它是该工具的旧版本。

更新:根据评论,原作者执行了上述操作,发现虽然poolmon报告非分页池的总大小确实很大,但所有分配的部分似乎都很小。我的猜测(也在评论中)是,这是由于我称之为“膨胀”的池:池被分配,然后释放,但出于某种原因,分配给池的RAM量没有缩小以反映“释放”。按照中描述的过程这个答案通过 magicandre 可以识别出罪魁祸首。

相关内容