Windows 使用过多的 RAM,如何诊断资源占用过大

Windows 使用过多的 RAM,如何诊断资源占用过大

我有 16GB 的系统 RAM。启动时,除了任务管理器之外没有打​​开任何应用程序,Windows 占用了大约 3GB 的 RAM。我查看了进程选项卡,但似乎没有什么异常。我如何找出我的 Windows 占用这么多 RAM 的原因。

在此处输入图片描述

所有用户的所有进程

在此处输入图片描述


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

在此处输入图片描述


重新安装与内存泄漏相关的无线驱动程序后。我有一张新的屏幕截图,想确认这确实是内存泄漏。

在此处输入图片描述

答案1

驱动程序导致内存泄漏。查看非分页内核内存的高值。在您的例子中,该值超过 3.7 GB。您可以使用池妖查看哪个驱动程序导致高使用率。

安装Windows WDK,运行poolmon,按池类型排序P,使非分页位于顶部,按B字节排序,查看使用最多内存的标签。转到安装WDK的文件夹运行poolmon,转到工具(或C:\Program Files (x86)\Windows Kits\10\Tools\x64)并单击poolmon.exe。

现在查看哪个pooltag使用了最多的内存,如下所示:

在此处输入图片描述

现在打开 cmd 提示符并运行 findstr 命令。为此,打开 cmd 提示符并输入“cd C:\Windows\System32\drivers”(不带引号)。然后输入“findstr /s __",其中 __ 是标签(poolmon 中最左边的名称)。执行此操作以查看哪个驱动程序使用此标签:

在此处输入图片描述

现在,转到驱动程序文件夹 (C:\Windows\System32\drivers),然后右键单击有问题的驱动程序(上图示例中的 intmsd.sys)。单击“属性”,转到“详细信息”选项卡以查找“产品名称”。查找该产品的更新。

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

你有用xperf 来追踪导致使用的原因. 安装Windows SDK 中的 WPT,打开以管理员身份运行 cmd.exe然后运行:

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-60 秒的增长。使用 WPA.exe 打开 ETL,将池图添加到分析窗格。

将pooltag列放在第一位,并添加stack列。现在加载符号进入 WPA.exe 并展开您在 poolmon 中看到的标签堆栈。

在此处输入图片描述

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

答案2

好吧,首先,在我给出更详细的答案之前。在您的第一个屏幕截图中,您的非分页池(一种内核内存使用情况)为 1.3GB。这对我来说似乎异常高,尤其是在启动后仅 30 分钟内。我猜我可以看到 NP 池在长时间使用后或使用像筛子一样泄漏的程序后变得如此之高。相比之下,我的 NP 池通常在 100 到 200 兆字节之间,而我的分页池可能高达 400 或 500(这是在我的系统连续数周未重新启动的情况下运行之后。)


您可以通过右键单击列标题并选择选择列来启用任务管理器中的几个附加列。您应该添加、、Working Set (private)和。我会扫描所有用户的所有进程,看看其中是否有任何进程的 NP 池超过 256KB。如果您看到任何,尤其是任何明显更高的,那可能是问题的根源,或者至少是问题的一部分。Working Set (shared)CommitNP Pool

总工作集,即进程使用的物理内存量,是私有工作集和共享工作集 (WS) 的总和。对于大多数进程来说,私有工作集通常更大,但是有些进程可能使用更大的共享工作集。两者通常相加等于总工作集。提交量是已提交到后备存储(在大多数情况下为 Windows 页面文件)的工作集量。后台应用程序的提交量通常大于 WS,这表明其大部分分页池已从内存中交换到分页文件中(对于已最小化且一段时间未使用的桌面应用程序而言,这很正常)。

非分页池是无法、也永远不会从物理内存中交换出来的内存……这实际上是您永久的最低物理内存使用量。NP 池内存通常包含程序代码和关键部分,这些代码和部分必须位于物理内存中才能正确或安全地运行,还有特殊堆等。在 60 个进程中,如果所有进程都有 256KB 的 NP 池内存,那么您的绝对最低物理内存使用量将约为 15,360KB。在大多数情况下,一两个应用程序可能有一个 256KB 的 NP 池,而大多数应用程序的 NP 池更少,通常要少得多(或没有)。系统极不可能将所有进程的工作集全部分页,因此永远不要指望内存使用量会变得那么低。


最后,拥有更多内存的目的是避免在物理磁盘上的扩展内存空间(交换、页面文件)中来回分页数据。分页是一个过程,涉及移动分配的物理内存块,将一些内存块推送到磁盘,并将其他内存块从磁盘移入物理内存。简单来说,分页是非常不受欢迎的。它本身并不“糟糕”,但如果分页发生得太频繁,可能会真正拖累性能。增加系统中总物理 RAM 的最终目的是允许更多进程将更多提交保留在物理内存中(更大的工作集)。消耗内存不是问题,当更多执行进程使用更多内存时,系统总体性能和活动进程性能通常会更高,因为与内存访问(特别是页面错误)相关的物理磁盘活动会更少。

Windows 为您管理内存,并自动将数据分页到页面(交换)文件和从页面(交换)文件移出内存。如果您运行的进程需要 9GB 内存,而您的系统已经使用了 4GB(共 12GB),那么系统将自动确定哪些进程不需要立即访问其整个工作集,并且它将部分或全部分页池分页到交换区以释放额外的 1GB。如果您的大进程最终需要更多内存,Windows 将进一步减少其他进程的工作集,直到它有足够的可用空间来分配新请求的块。您的大进程最终可能会消耗除 NP 池之外的所有可用内存,并且可能还会消耗一些额外的最小开销,用于定期执行不允许 Windows 释放更多工作集的进程(即它们有待处理的页面错误,否则 Windows 会将其从物理内存中交换出去,但由于它们正在被请求,因此无法移动。)

如果进程需要的内存超过允许访问的内存(32 位进程通常可以访问 2Gb,有些使用增强技术可以访问不到 4Gb,而 64 位进程通常每个可以访问大约 48Gb 的内存),那么 Windows 有时会尝试使用交换空间虚拟化其内存。如果 32 位应用程序想要使用其允许的最大 2Gb 空间,但只有 1.2Gb 可用,Windows 将在页面文件中保留完整的 2Gb,并根据需要将进程自己的数据移入和移出页面文件,以支持应用程序的内存使用。在这种情况下,按总提交量计算,总“内存”使用量可能看起来大于可用的物理内存。总提交量通常最大为总页面文件大小,当由系统管理时,通常是物理内存量的 2-3 倍。在您的情况下,总提交量大约为 24Gb,或 12Gb 物理内存的 2 倍(这在您的第一个屏幕截图中显示,其中显示:提交(GB)3/23)。


最后一点。您在回答中说您有 16GB 的 RAM,而任务管理器只显示 12GB 的 RAM。这里有两种情况。要么您的系统确实只有 12GB 的 RAM,要么您的某根内存条未正确注册。如果一根内存条(我假设是 4 根 4GB 内存条),则可能是坏了,可能没有完全正确地安装在主板上,或者您的主板可能存在内存检测问题。

要检查是否是后者,您首先应将主板 BIOS 更新到最新版本。我遇到过类似的问题...我的六根三通道 DDR3 内存条(6x 2GB)在单独测试每根内存条时都很好...但我的主板偶尔会随机决定不计算其中的一两根内存条,导致内存条经常只剩下 8GB。BIOS 更新解决了这个问题,现在我可以可靠地访问我的所有 12GB 内存。

答案3

我如何才能知道为什么我的 Windows 使用了这么多 RAM?

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

如果你在想“我现在想释放我的 RAM,以便以后使用”,那就算了吧。RAM 不必现在释放,以后就可以使用。你可以现在使用它稍后再使用。这里的权衡——使用 RAM 绝对没有任何坏处。

RAM 一直处于使用状态,可以直接从一种用途切换到另一种用途,而无需费力将其释放,然后才能再次使用。现代操作系统只有在别无选择的情况下才会让 RAM 保持空闲状态。

答案4

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

我能够识别它具有出色的实用性拉姆地图

在此处输入图片描述

屏幕截图来自之后。之前,“驱动程序锁定”内存超过 6GB,超过此特定机器的 80% 的 RAM。我不得不进入 Hyper-V 管理器并禁用“动态内存”。奇怪的是,即使重新启用它,“驱动程序锁定”内存仍然很低 - 我只能假设之前的实例增加了它,并且 Hyper-V 不会自动减少其分配的内存:

在此处输入图片描述

相关内容