我的 64 位 Windows 7 PC 运行非常缓慢。我注意到任务管理器中的内存使用率接近 100% - 但是每个进程报告的使用量加起来并不等于总共 6GB（Firefox 显示大约 500MB，其余的则少得多）。我下载了内存地图并发现页表占用了相当多的内存（2.5GB）。
我谷歌了一下，但一无所获——显然页表可能会碎片化。显然我会重启机器，看看是否有帮助。但有没有更好的方法来修复它？
编辑：重新启动，页表降至 30MB。
编辑 2：运行几天后，页表使用量再次上升。我按照 @magicandre1981 的说明进行操作这个答案查找页表使用来源。不幸的是，我一无所获——页表由“未知”使用！
有人有什么好主意吗？
答案1
打开 RamMap 中的“进程”选项卡，按名称排序。查找可疑的大量相同进程。在我的计算机上，“SynTPEnh.exe”是罪魁祸首（触摸板驱动程序的一部分）。运行一周后，它在页表中积累了数万个条目，每个条目大小为 32kb。
我的页表大小为 1 GB，重启后就只有 50 MB。
答案2
我需要对问题的评论进行评论，特别是“页表”和“页面文件”之间的混淆。这不是答案，但它不适合评论的空间。
“页表”确实与页面文件有很大不同。n用于页表的 RAM MB 并不意味着您正在使用nMB 的页面文件空间。尽管有些页表条目 (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（靠近根（以及根本身）的 PTE）指示下一个较低级别的表的位置（如果它们存在的话）。
RAMmap 显示的数字是所有进程和操作系统的所有常驻（RAM 内）页表占用的物理内存（RAM）。
这里重要的是，OQ 中的系统有 2.5 GB 的 RAM 与页表绑定在一起。这意味着，至少定义了 2.5 GB 的页表。由于页表本身是可分页的，因此虚拟大小可能比物理大小大得多，这是 RAMmap 可以向我们显示的全部。但假设它“只有”2.5 GB。每个 PTE 有 8 个字节，大约有 3.2 亿个 PTE。由于每个 PTE 定义一个页面（4K 字节）的虚拟地址空间，这意味着超过 1.2兆兆字节虚拟地址空间定义为在记忆中页表。
这并非不可能，但数量相当多。
作为参考，在我的系统上，目前我的页表中有大约 125 MB 的 RAM。这意味着只有大约 65 GB 的虚拟地址空间。我的实际虚拟使用率要高得多（仅用于进程就有 125 TB），但这是因为大多数页表不在 RAM 中。“大页面”是另一个我不应该在这里讨论的东西，它也可以解释页表大小与正在使用的虚拟地址空间大小之间的不同比率。
因此：为了找到罪魁祸首，我首先要在性能监视器的进程类别下查找“虚拟字节”计数器值较高的进程。
答案3
联想“RapidBoot Shield”是我的罪魁祸首。
一周没有重启后，我的“页表”占用了 4GB 以上。事实证明，每个终止的进程都使用 20K RAM（4K 私有，16K 页表），如 RamMap 的“进程”选项卡中所示，并且有大约 200,000 个进程！
重新启动后列表变小了，但列表又开始变大了。通过打开记事本、将其终止并观察它是否停留在 RamMap 进程列表中，可以重现此情况。
根据建议此 Technet 主题我卸载了“RapidBoot Sheild”，重启了机器，然后进程在被终止后就不再存在了。问题解决了！
答案4
我向 IT 部门咨询了这个问题，他们也同样被迷惑了。最后我使用了駕駛易更新我的驱动程序。奇怪的是，似乎产生影响的是显示器驱动程序。以前我使用的是标准的 Windows“通用即插即用显示器”驱动程序。但当我将这些驱动程序更新为显示器的正确品牌和型号时，问题似乎消失了。