为什么我的页表要占用这么多内存？

Question

我的 64 位 Windows 7 PC 非常缓慢。我在任务管理器中注意到我的内存使用率接近 100% - 但是每个进程报告的使用量加起来没有达到总 6GB（Firefox 显示大约 500MB，其余的更少）。我下载了RAMMap，发现Page Table占用了相当大的内存（2.5GB）。

我用谷歌搜索了这个并没有找到 - 显然页表可能会碎片化。显然我会重新启动机器，看看是否有帮助。但是有没有更好的方法来修复它？

编辑：重新启动，页表减少到 30MB。

编辑 2：经过几天的正常运行时间，页表的使用再次上升。我按照这个答案中@magicandre1981 的说明找到了页表使用的来源。不幸的是我画了一个空白 - 页表被“未知”使用！

有人有什么好主意吗？

Answer 1

打开 RamMap 中的“进程”选项卡并按名称排序。查找数量可疑的相同进程。在我的机器上，“SynTPEnh.exe”是罪魁祸首（触摸板驱动程序的一部分）。经过一周的正常运行，它在页表中积累了数万个条目，每个条目大小为 32kb。

我的页表大小是 1 GB，重启后只有 50 MB。

Answer 2

联想“RapidBoot Shield”是我的罪魁祸首。

一周没有重新启动后，我的“页表”使用了 4GB+。事实证明，每个终止的进程都使用 20K RAM（4K 专用、16K 页表），如 RamMap 的“进程”选项卡所示，其中大约有 200,000 个！

重新启动减少了列表，但它又开始增长。通过打开记事本、杀死它并观察它保留在 RamMap 进程列表中，可以重现它。

根据此 technet 线程的建议，我卸载了“RapidBoot Sheild”，重新启动计算机，然后进程在被杀死时不再保留。问题解决了！

Answer 3

我需要对问题的评论发表评论，特别是“页表”和“页面文件”之间的混淆。这不是一个答案，但它不适合评论的空间。

“页表”确实与页面文件非常不同。将n MB 的 RAM 用于页表并不意味着您正在使用n MB 的页面文件空间。尽管一些页表条目（PTE，页表由页表组成）确实引用了页面文件内容，但并非全部如此。

页表是用于由CPU的MMU进行内存结构的地址转换从虚拟地址（再次，没有页面文件）为物理地址，并通过操作系统来跟踪虚拟地址空间，并帮助解决页面错误的。页表由页表条目 (PTE) 组成。每个 PTE 占用 8 个字节并定义了 4K 字节的虚拟地址空间——即一个虚拟页面。粗略地说，虚拟地址空间的每个非空闲页面都有一个 PTE。

顺便说一下，尽管页面文件可能会遇到外部和内部碎片（前者通常不是什么大问题；后者可以通过将其增大到所需大小的四倍来改善），但页表却不能。它们已经有点总是支离破碎的，这无关紧要。

每个 PTE 都有一个“有效”位。对于“有效”，也就是“常驻”页面，PTE 包含与与 PTE 关联的虚拟页码对应的物理页码；这直接由 MMU 使用。

对于“无效”页面，MMU 引发页面错误，然后 PTE 具有许多可能的格式和解释。

注意：以上所有内容都适用于在 x86/x64 上启用分页的任何操作系统。以下主要针对 Windows，但许多概念适用于其他操作系统，但在实现细节上有所不同。

对于页缓存中的一个页，PTE 仍然包含物理页号。对于从 RAM 中丢失并写入页面文件的页面，PTE 确实包含页面文件编号和页面文件中写入页面内容的偏移量。其他可能的 PTE 内容是对虚拟地址描述符的引用、对“原型 PTE”的引用、对需求零页的引用等，我不打算讨论这些内容。可以说只有一些 PTE 引用了页面文件中的位置。

我提到所有这些主要是为了表明页面文件和页表虽然相关，但绝对不是一回事。

页表被组织成树状结构。每个进程都有一个不同的这样的树或页表集合——这允许每个进程定义自己的虚拟地址空间实例。树根的页表必须始终在 RAM 中。其他是可分页的；在它们对应于未定义或空闲虚拟地址空间的大（最小 2 MB）区域的地方，它们甚至不存在。

树的“叶子”处的表中的页表条目对应于虚拟地址空间的页。更高级别表中的 PTE - 更接近根（和根本身）的表 - 告诉下一个较低级别的表在哪里（如果它们存在的话）。

RAMmap 显示的数字是所有进程加上操作系统的所有常驻（内存中）页表占用的物理内存（RAM）。

这里重要的是 OQ 中的系统有 2.5 GB 的 RAM 与页表相关联。这意味着，至少定义了 2.5 GB 的页表。由于页表本身是可分页的，因此虚拟大小可能比物理大小大得多，这就是 RAMmap 可以向我们展示的全部内容。但假设它“只有”2.5 GB。每个 PTE 8 个字节，大约有 3.2 亿个 PTE。由于每个 PTE 定义了一页（4K 字节）的虚拟地址空间，这意味着超过 1.2 TB的虚拟地址空间由内存页表定义。

这并非不可能，但它相当多。

作为参考，在我的系统 atm 上，我在页表中有大约 125 MB 的 RAM。这表示只有大约 65 GB 的虚拟地址空间。我的实际虚拟使用量要高得多（仅用于进程 125 TB），但这是因为大多数页表不在 RAM 中。“大页面”，我不应该在这里涉及的另一件事，也可以帮助解释页表大小与使用中的虚拟地址空间大小之间的不同比率。

所以：为了找到罪魁祸首，我首先会在进程类别下的性能监视器中查找具有高“虚拟字节”计数器值的进程。

Answer 4

我向我的 IT 部门询问了此事，他们也同样感到困惑。我最终使用DriverEasy来更新我的驱动程序。奇怪的是，似乎造成差异的是显示器驱动程序。以前我有标准的 Windows“通用 PnP 监视器”驱动程序。但当我将它们更新为显示器的正确品牌和型号时，问题似乎就消失了。