为什么 Resource Monitor 和 Task Manager 的总 RAM 使用量甚至远未加总物理内存使用量？

Question

我在许多不同的 Windows 机器上，在许多不同的场合注意到这一点：任务管理器或资源监视器报告的 RAM 使用量似乎通常加起来显着低于实际使用量。

例如，很多次在我的笔记本电脑或台式机上，我看到使用了 7GB 之类的东西，但工作 RAM 集的总数更像是 3GB。我就是不知道它在哪里被使用！

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

^{点击查看全尺寸}

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

现在这是任务管理器的性能选项卡的屏幕截图：

^{点击查看全尺寸}

这表示 7.6GB 的物理内存正在使用中。

我一直在个人计算机、笔记本电脑和现在的服务器上看到这一点：系统工具报告的总 RAM 使用量仅占我观察到的 RAM 使用量的 1/4 左右。跆拳道要开始了？？？

对我所有的 RAM 在哪里有任何令人满意的解释吗？是什么吞噬了它，为什么它不留痕迹？

编辑：这是用户 whs 要求的图形 RAM 使用的图片：

^{点击查看全尺寸}

编辑 2：为了回应 James 的回应，这里是 中非分页进程的图片poolmon.exe，按大小排序：

这些结果让我很困惑。poolmon正确说明我有 6GB 的非分页池正在使用，但所有非分页池进程的大小都小于 8MB。

这意味着什么？是否poolmon未能检测到使用非分页池的某些进程？

Answer 1

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

或者更客气地说：大量使用不在进程的私有工作集中的 RAM。其中一些位于进程的共享工作集中 - 但由于共享，您无法获得那里实际使用情况的可靠概念；将进程的数字相加会给您带来太大的结果。

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

关于您的具体问题：

在任务管理器显示上，看到“内核内存”部分了吗？您有 6 GB 的“非分页内存”（即非分页池）。这是第二张图中“使用中”部分的一部分。非分页池不向任何进程收费，这就是为什么在任务管理器中添加每个进程的数量不会接近使用的总数。某些驱动程序最有可能使用它。这是一个完全过量的数量；它应该远低于 1 GB。任何负责非分页池使用过多部分的驱动程序无疑都是错误的。

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

查找方法如下： 获取 Microsoft 工具“poolmon”的副本。它是一个字符模式工具（男孩，它曾经是）随 Windows 驱动程序工具包分发。对于 Windows 7，WDK 是免费下载的。你必须下载整个东西（它是一个 ISO）并从中安装它，但你可以选择只安装工具，如果这就是你想要的。

在 WDK 目录中找到 poolmon - 确保选择正确的 32 位或 64 位 - 并从管理员命令提示符运行它。你会得到这样的显示：

现在，按“p”键（不，我不是在开玩笑。这里没有菜单！），直到“类型”列只显示“Nonp”。然后按“b”（必要时两次）按字节列（此处的示例中已完成）按降序对显示进行排序。

然后查看最上面一行的“标签”列。在此处显示的（显然是人为的）情况下，它是“泄漏”。（这个系统正在运行一个被故意窃听导致这个问题的驱动程序 - 它“泄漏”了非分页池。）

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

现在在 c:\Windows\System32\Drivers 中搜索包含该字符串的 .sys 文件。在这种情况下，您将寻找“泄漏”，如下所示：

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

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

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

（我敢打赌，您找到的标签将是 ECMC，驱动程序是 intmsd.sys，并且它与名为 ExpressCache 或 IntelliMemory 的产品相关联。我会“卸载”该产品。有一个更新可以解决这个问题，但即使使用固定版本时，我从未见过该产品提高了系统性能；它本质上复制了 Windows 中已有的功能。）

如果您找不到那样的方法，下一步是使用“Windows Performance Toolkit”。在此论坛中搜索该字符串，以及由 magicandre1981 提供的答案，以获取操作方法。忽略提到 xperf 的答案 - 它是该工具的旧版本。

更新：根据评论，OP 执行了上述操作，发现尽管 poolmon 报告非分页池的总大小确实很大，但所有分配的部分显然很小。我的猜想（也在评论中）是由于我将称之为“膨胀”的池：池已分配，然后被释放，但由于某种原因，分配给池的 RAM 量并未缩小以反映“释放” . 按照magicandre在此答案中描述的程序可能会确定罪魁祸首。