2013-11-12 01:10:06 +0000 2013-11-12 01:10:06 +0000
75
75

Windows使用内存过大,如何诊断资源占用?

我有16GB的系统内存。在启动时,除了任务管理器外,没有打开任何应用程序,Windows使用了大约3GB的内存。我查看了进程选项卡,但似乎没有什么不正常的地方。我如何才能找出为什么我的Windows使用了这么多的RAM。

来自所有用户的所有进程


从poolmon中读取,似乎我的无线宽带驱动程序使用了大约0.4GB的内存。即使我删除了它,它仍然会在启动时使用2.6GB,这仍然是太多了。


在重装了与内存泄漏相关的无线驱动后。我有一张新的截图,想确认一下,确实是内存泄漏。

答案 (4)

85
85
85
2013-11-12 04:54:18 +0000

你有一个由驱动程序引起的内存泄漏。查看非paged内核内存的高值。在你的情况下,这个值超过了3.7 GB。你可以使用 poolmon 来查看是哪个驱动导致了高使用率。

安装 Windows WDK ,运行 poolmon,在 pool 类型后用 P 排序,使 non paged 放在最上面,在 bytes 后用 B 排序,查看使用内存最多的标签。运行poolmon的方法是进入安装WDK的文件夹,进入工具(或C:\Program Files (x86)\Windows Kits10\Tools\x64),然后点击poolmon.exe。

现在看看哪个池标签使用的内存最多,如图所示。

现在打开cmd提示符,运行findstr命令。要做到这一点,打开cmd提示符并键入 “cd C:\Windows\System32\drivers",不用引号。然后键入 "findstr /s ____.",其中 __是标签(poolmon中最左边的名字)。这样做可以查看哪个驱动使用了这个标签。

现在,进入drivers文件夹(C:\Windows\System32\drivers),右键点击问题驱动(上图中的intmsd.sys)。单击 "属性",进入详细信息选项卡,找到 "产品名称"。寻找该产品的更新。

如果 pooltag 只显示 Windows 驱动程序或在 pooltag.txt 中列出 ("C:\Program Files (x86)\Windows Kits.1\Debuggers\x64\triage\pooltag.txt")

你有使用 xperf 来跟踪是什么原因导致的使用 。安装 Windows SDK 中的 WPT ,打开一个 cmd.exe as admin ,然后运行这个。

xperf -on PROC_THREAD+LOADER+POOL -stackwalk PoolAlloc+PoolFree+PoolAllocSession+PoolFreeSession -BufferSize 2048 -MaxFile 1024 -FileMode Circular && timeout -1 && xperf -d C:\pool.etl

捕获30 -60s的增长。用WPA.exe打开ETL,将Pool图添加到分析窗格中。

把pooltag列放在第一位,并添加堆栈列。现在加载符号在WPA.exe里面,展开在poolmon中看到的tag的栈。

现在找到其他第三方驱动,你可以在堆栈中看到。这里的Thre标签(线程)被G-Data的AVKCl.exe使用。寻找驱动程序/程序更新来修复它。

15
15
15
2013-11-12 05:41:48 +0000

好吧,首先,在我进行更详细的回答之前。在你的第一张截图中,你的Non-Paged Pool(一种内核内存使用量)是1.3GB。这在我看来是不寻常的高,尤其是在启动后仅30分钟的情况下。我想我可以看到NP Pool在长时间使用后会变得这么高,或者是程序像筛子一样漏水。相比之下,我的NP Pool通常在100到200兆之间,而我的分页池可能高达400或500(这是在我的系统运行了几个星期而没有重启的情况下)


你可以在任务管理器中通过右击列头,选择选择列来启用一些额外的列。你应该添加Working Set (private)Working Set (shared)CommitNP Pool。我会扫描你所有用户的所有进程,看看是否有任何进程的NP Pool超过256KB。如果你看到任何一个,特别是任何一个比这个高得多的进程,那可能是问题的根源,或者至少是问题的一部分。

你的总工作集,即一个进程使用的物理内存量,是私有和共享工作集(WS)的组合。对于大多数进程来说,私有工作集通常更大,但也有一些进程可能会使用更多的共享WS。两者之和通常应该是总WS。Commit是已经提交到备份存储中的工作集的数量(在大多数情况下,Windows页面文件)。后台应用程序的Commit经常大于WS,这表明它们的分页池的大部分已经从内存中换出,并进入您的分页文件(对于已经最小化并有一段时间没有使用的桌面应用程序来说,这很正常)。

非分页池是不能,也永远不会从物理内存中交换出来的内存……这实际上是你永久的最低物理内存使用量。NP Pool内存通常包含了必须在物理内存中才能正确或安全运行的程序代码和关键部分,特殊的堆等。在60个进程中,如果所有进程都有256KB的NP Pool内存,那么你的绝对最小物理内存使用量将是15,360KB左右。在大多数情况下,一两个应用程序可能会有256KB的NP Pool,而大多数应用程序的NP Pool更少,通常会少很多(或者没有)。系统不太可能将所有进程的工作集全部翻出来,所以千万不要指望内存使用量会这么低。


最后,拥有更多内存的目的是为了避免在物理磁盘上将数据分页到扩展的内存空间(swap,page文件)。分页是一个过程,它涉及到移动已分配的物理内存块,将一些数据推到磁盘上,并将其他数据从磁盘上带入物理内存。简单来说,分页是非常不可取的。它本身并不是 “坏事",但当它发生得太频繁时,会真正拖累性能。增加系统中的总物理内存的最终目的是让更多的进程在物理内存中保留更多的提交(更大的工作集)。消耗内存不是问题,当更多的执行进程使用更多的内存时,系统总性能和活动进程性能通常会更高,因为与内存访问相关的物理磁盘活动(特别是页面故障)会降低。

Windows为你管理内存,并为你自动将数据分页进出内存,并从分页(swap)文件中取出。如果你运行了一个需要9GB内存的进程,而你的系统已经使用了4GB(12GB中的),那么系统会自动找出哪些进程不需要立即访问它们的整个工作集,它将把它们的页池中的部分或全部页取出来交换,以便腾出那额外的1GB。如果你的大型进程最终需要更多的内存,windows会进一步减少其他进程的工作集,直到它有足够的空闲空间来分配新请求的块。你的大进程最终可能会消耗除了NP Pool以外的所有可用内存,或许还会消耗一些额外的最小开销,用于周期性执行进程,这些进程不允许windows腾出更多的工作集(即它们有悬而未决的页面故障,否则windows会将它们从物理内存中交换出来,但由于它们正在被请求,所以无法移动)。

如果一个进程需要的内存超过了它被允许访问的内存(32bit进程通常可以访问2Gb,有的在增强技术下可以访问不到4Gb,而64bit进程通常可以访问48Gb左右的内存,每个进程),那么windows有时会尝试用交换空间来虚拟它的内存。如果一个32位的应用程序想要使用其最大允许的2Gb空间,但只有1.2Gb可用,那么windows会在页文件中保留全部的2Gb,并根据需要将进程自己的数据移入和移出页文件,以支持应用程序的内存使用。在这种情况下,总的 "内存 "使用量可能会出现大于可用物理内存的情况,当按 总承诺。Total Commit通常会在总的页面文件大小时达到最大值,当系统管理时,通常是物理内存量的2-3倍。在你的情况下,Total Commit将是24Gb左右,或者说是12Gb物理内存的2倍(这在你的第一个屏幕截图中就有显示,它说:"Commit (GB) 3 / 23")。Commit (GB) 3 / 23).


最后一点。你在回答中说你有16Gb的内存,而任务管理器只看到12Gb的内存。这里有两种情况。要么是你的系统真的只有12Gb的内存,要么是你的一个内存棒没有正确注册。如果一个内存棒(我假设是4个4Gb的内存棒),它可能是坏的,可能没有完全正确地安装在你的主板上,或者你的主板可能有一个内存检测问题。

要检查是否是后者,你应该先把主板的BIOS更新到最新版本。我也遇到过类似的问题……我的六条Tripple-Channel DDR3内存(6x 2Gb)根据每条的单独测试都是好的……但我的主板每隔一段时间就会随机决定不计算其中的一两条,经常让我只剩下8Gb的内存。通过BIOS更新解决了这个问题,现在我可以可靠地访问所有12Gb的内存。

12
12
12
2013-11-12 01:35:00 +0000

我怎样才能知道为什么我的Windows使用了这么多的内存。

它使用这么多内存是因为它是被设计成这样的。使用RAM绝对没有任何成本。事实上,使用过的RAM比免费的RAM更好,因为操作系统不需要做任何事情就可以使用它。使用免费的RAM需要让它被使用,这需要付出努力。

如果你在想 “我希望我的RAM现在是免费的,这样我以后就可以使用它",那就别想了。RAM不一定要现在免费才能以后使用。你可以现在使用它_以后再使用它。这里没有任何权衡–使用RAM绝对没有任何缺点。

RAM被保留使用,并且直接从一个用途切换到另一个用途,而不需要费尽心思让它空闲出来,只是为了让它再次使用。现代操作系统只有在别无选择的情况下才会让RAM空闲。

2
2
2
2017-01-14 12:37:08 +0000

上面没有提到的一个原因是Hyper-V。

我能够用优秀的实用工具 RamMap 来识别。

这张是之后的截图 在 “驱动锁定 "之前,内存超过了6GB,超过了这台特殊机器80%的内存。我只好进入Hyper-V管理器,禁用了 "动态内存"。奇怪的是,即使重新启用后,"Driver Locked "内存仍然很低–我只能推测之前的实例增加了它,而且Hyper-V不会自动减少其分配的内存。