【问题标题】:What part of the process virtual memory does Windows Task Manager displayWindows 任务管理器显示进程虚拟内存的哪一部分
【发布时间】:2018-10-28 16:55:43
【问题描述】:

我的问题有点幼稚。我愿意尽可能简单地进行概述,但找不到任何让我清楚的资源。我是一名开发人员,我想了解 Windows 任务管理器中默认情况下“内存”列中显示的内存到底是什么:

为了让事情更简单一点,让我们忘记进程与其他进程共享的内存,并想象共享内存可以忽略不计。此外,我专注于大局,主要关注 GB 级别的事情。

据我所知,被称为“虚拟内存”的进程保留的内存部分存储在主内存(RAM)中,部分存储在磁盘上。系统决定什么去哪里。系统基本上将进程足够频繁地访问的虚拟内存部分保存在 RAM 中。一个进程可以保留比计算机中可用的 RAM 更多的虚拟内存。

从开发人员的角度来看,虚拟内存可能仅由程序通过其自己的内存管理器分配部分(例如malloc()new X())。我猜系统不知道分配了虚拟内存的哪一部分,因为这是由进程以“私有”方式处理的,并且取决于语言、运行时、编译器... 问:这是正确的吗?

我的假设是,任务管理器显示的内存本质上是系统存储在 RAM 中的虚拟内存的一部分。 问:对吗?有没有一种简单的方法可以知道进程保留的总虚拟内存?

【问题讨论】:

  • 如果您将鼠标悬停在列标题上,则会显示一个工具提示。您也可以切换到Detail 选项卡并在那里选择感兴趣的列。它有大约 12 种不同的内存指标可用。

标签: c++ windows memory memory-management ram


【解决方案1】:

Windows 上的内存...非常复杂,询问“我的进程使用了​​多少内存”实际上是一个无意义的问题。要回答您的问题,让我们先了解一些背景知识。

Windows 上的内存通过ptr = VirtualAlloc(..., MEM_RESERVE, ...) 分配,稍后通过VirtualAlloc(ptr+n, MEM_COMMIT, ...) 提交。

任何保留的内存都只会用完地址空间,因此并不有趣。 Windows 会让你MEM_RESERVE TB 的内存就好了。提交内存确实会消耗资源,但不会像您想象的那样。当您调用提交窗口时,会进行一些总和并且基本上可以计算出来(总物理内存 + 总交换 - 当前提交),如果有足够的空闲空间,您可以分配内存。但是,在您实际使用它之前,Windows 内存管理器实际上不会给您物理内存。

但是,稍后,如果 Windows 的物理 RAM 太紧,它会将您的一些 RAM 交换到磁盘(它可能会压缩它并丢弃未使用的页面,丢弃从文件直接映射的任何内容和其他优化)。这意味着您的程序的总提交和总物理内存使用量可能会有很大不同。这两个数字都很有用,具体取决于您要测量的内容。

还有最后一个重要的警告 - 共享内存。当您加载 DLL 代码时,只读内存 [甚至可能是读/写部分,但这是 COW'd] 可以与其他程序共享。这意味着您的应用需要该内存,但您不能仅针对您的应用计算该内存 - 毕竟它可以共享,因此不会像天真的计数所认为的那样占用那么多的物理内存。

(如果您正在编写游戏或类似游戏,您还需要计算 GPU 内存,但我不是这里的专家)

上述所有优点通常都被应用程序使用的堆包裹起来,而你什么也看不到——你要求并使用内存。并且尽可能地优化。

您可以通过转到详细信息选项卡并查看各种选项来看到这一点 - 提交大小和工作集非常有用。如果您只查看任务管理器中的主窗口并且它只有一个值,我希望您现在明白,所用内存的单个值必须是某种妥协,因为这不是一个有意义的问题。

现在回答你的问题

首先,操作系统确切地知道您的应用保留了多少内存以及它已提交了多少。它不知道的是,您(或更可能是 CRT)正在使用的堆实现是否保留了一些尚未释放回操作系统的已释放内存。堆通常这样做是为了优化 - 从操作系统请求内存并将其释放回操作系统是一项相当昂贵的操作(并且只能在称为页面的大块中完成),因此它们中的大多数都会保留一些。

第二个问题:不要使用该值,转到详细信息并使用那里的值,因为只有你知道你真正想问什么。

编辑:

对于您的评论,是的,但这取决于分配的大小。如果您分配一大块内存(例如 >= 1MB),则 CRT 中的堆通常直接将分配推迟到操作系统,因此释放单个内存实际上会释放它们。对于小的分配,CRT 中的堆向操作系统请求内存页面,然后将其细分以在分配中给出。因此,如果您随后释放所有其他人,您将留下漏洞 - 并且堆不能将这些漏洞还给操作系统,因为操作系统通常只能在整个页面中工作。因此,您在任务管理器中看到的任何内容都会显示所有内存仍在使用中。请记住,此内存不会丢失或泄漏,它只是有效地池化,如果分配要求该大小,它将再次使用。如果你关心这段记忆,你可以使用crt heap statistics famliy of functions 来关注那些——特别是_CrtMemDumpStatistics

【讨论】:

  • 谢谢。我可能非正式地使用了“承诺”这个词。我不确定我们的意思是一样的。想象一下,你做了 200 万次 malloc(2)。然后释放 2 个活 100 万个洞中的一个。我所说的“承诺”是剩下的100万。系统真的有这个意识吗?
  • @BenoitSanchez 我已经编辑了答案,希望对您有所帮助,但是 tldr 是的,您是对的 - 操作系统不知道这些漏洞。
  • @MikeVine 实际上是这样,HeapAlloc 是在VirtualAlloc 之上实现的系统的基础mallocHeapAlloc 有一个 'LowFragmentationHeap' 用于小分配,并且非常擅长尽其所能释放不再使用的页面等。显然,如果您没有足够的空闲空间让整个页面被释放。
  • @Mike。好的。我知道了。谢谢。您添加的文字对我的理解非常重要。
  • @Mgetz 当然——如果整个页面是空闲的,那么堆可以将它释放回操作系统——但是使用这里描述的使用模式(分配 100 万个小对象,释放每个其他的)那么即使使用 LFH,也很有可能每次分配都是相当连续的,因此没有完整的空闲页面,只有很多页面使用率约为 50%。
猜你喜欢
  • 2014-03-19
  • 2012-01-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-12-24
  • 2011-06-25
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多