为什么我的页表占用了这么多内存?


10

我的64位Windows 7 PC非常缓慢。我在任务管理器中注意到,我的内存使用率接近100%-但是,每个进程报告的使用率总计不超过6GB(Firefox显示约500MB,其余更少)。我下载了RAMMap,发现页面表占用了大量内存()。

RAMMap屏幕截图

我用这个搜索了一下,却一无所获-显然页表可能会碎片化。显然,我将重新启动计算机,看看是否有帮助。但是,有更好的解决方法吗?

编辑:重新启动,并且页表下降到30MB。

编辑2:经过几天的正常运行时间后,页表的使用率再次攀升。我在这个答案中遵循了@ magicandre1981的指示来查找页表用法的来源。不幸的是,我画了一个空白-页面表被“未知”使用!

WPA屏幕截图

有人有什么好主意吗?


您必须确定正在使用页面文件的内容,以了解页面文件(即虚拟内存)使用率很高的原因。
拉姆猎犬,2014年

1
不,我认为这是使用中的物理内存,而不是虚拟的。我以为页是内存管理器的某种参考?
benshepherd 2014年

2
正如我在问题中所说的,没有任何进程正在使用内存。我的印象是页面与页面文件是不同的东西。
benshepherd 2014年


1
页表与页文件完全不同。请参阅下面的答案。同样,尽管页面文件可能会碎片化,但是页表……好吧,它们总是碎片化(就像分散在整个RAM中一样),丝毫没有关系。
Jamie Hanrahan 2015年

Answers:


5

我需要评论这个问题,特别是“页面表”和“页面文件”之间的混淆。这不是一个答案,但它不能容纳在注释中。

“页面表”确实与页面文件有很大不同。具有n MB的RAM用于页表并不意味着您正在使用n MB的页文件空间。而且,尽管某些页表条目(页表所组成的PTE)确实引用了页文件的内容,但并非全部。

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

顺便说一句,尽管页面文件可以同时经历内部和内部碎片(前者通常不是什么大问题;后者可以通过使其变成所需大小的四倍来改善),但是页表却不能。它们已经总是零散了,一点也没有关系。

每个PTE都有一个“有效”位。对于“有效”页面(也称为“驻留”页面),PTE包含与该PTE关联的虚拟页面编号相对应的物理页面编号;它由MMU直接使用。

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

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

对于页面缓存中的页面,PTE仍包含物理页面号。对于已从RAM中丢失并写入页面文件的页面,PTE确实包含页面文件编号和页面内容写入页面文件内的偏移量。其他可能的PTE内容是对虚拟地址描述符的引用,对“原型PTE”的引用,对需求零页的引用等,我将不介绍它们。只需说一些PTE引用页面文件中的位置就足够了。

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

页表被组织成树状结构。每个进程都有一个不同的树或页表集合-这就是允许每个进程定义自己的虚拟地址空间实例的原因。树根的页表必须始终位于RAM中。其他可分页;它们甚至不存在,它们对应于未定义或可用的虚拟地址空间的大区域(至少2 MB)。

在树的“叶子”处的表中的页面表条目对应于虚拟地址空间的页面。较高级别的表中的PTE-靠近根(以及根本身)的PTE告诉下一个较低级别的表在哪里(如果它们根本存在)。

RAMmap显示的数字是所有进程以及OS的所有驻留(RAM中)页表所占用的物​​理内存(RAM)。

在这里重要的是,OQ中的系统有2.5 GB的RAM与页表捆绑在一起。这意味着至少定义了2.5 GB的页表。由于页表本身是可分页的,因此虚拟大小可能比物理大小大得多,这是RAMmap可以向我们显示的全部。但是假设它只有2.5 GB。每个PTE八个字节大约为3.2亿个PTE。由于每个PTE都定义了一个页面(4K字节)的虚拟地址空间,这意味着内存页表定义了超过1.2 TB的虚拟地址空间。

这不是不可能,但是很多。

作为参考,在我的系统atm上,页表中有大约125 MB的RAM。这将仅指示大约65 GB的虚拟地址空间。我的实际虚拟使用率要高得多(仅用于进程时为125 TB),但这是因为大多数页表不在RAM中。“大页面”是我不应该在这里讨论的另一件事,它也可以帮助说明页面表大小与使用中的虚拟地址空间大小之间的不同比率。

因此:要找到罪魁祸首,我首先要在“性能监视器”中的“进程”类别下查找“虚拟字节”计数器值较高的进程。


4

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

一个星期没有重启后,我的“页面表”使用了4GB以上的内存。事实证明,每个终止的进程都使用20K RAM(4K私有,16K页表)卡住,如RamMap的“进程”选项卡所示,其中约有200,000个!

重新启动减少了该列表,但它又开始增长。通过打开记事本,将其杀死并观察它是否保留在RamMap进程列表中,可以复制该文件。

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



1

我向我的IT部门询问了这一点,他们同样感到困惑。我最终使用DriverEasy更新了我的驱动程序。似乎很重要的是监视器驱动程序。以前,我有标准的Windows“ Generic PnP Monitor”驱动程序。但是,当我将其更新为显示器的正确品牌和型号时,问题似乎消失了。


1

在RamMap中打开“进程”选项卡,然后按名称排序。查找同一进程的数量多得可疑。在我的机器上,“ SynTPEnh.exe”是罪魁祸首(触摸板驱动程序的一部分)。一周的正常运行时间后,它积累了页表中的成千上万个条目,每个条目的大小为32kb。

我的页面表大小为1 GB,重新启动后只有50 MB。

在此处输入图片说明

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.