在我的 Windows XP 任务管理器中，某些进程在“内存使用情况”列中显示的值高于“VMSize”。 例如，我的 Firefox 实例显示内存使用量为 111544 K，VMSize 显示为 100576 K。
根据任务管理器的帮助文件，MemUsage是进程的工作集，VMSize是虚拟地址空间中提交的内存。
我的问题是，如果一个进程的已提交页面数为 A，同一进程的物理内存中的页面数为 B，那么它不应该总是 B ≤ A 吗？ 每个进程的物理内存中的页数不是已提交页的子集吗？
或者这与进程之间共享内存有关？ 请解释。 （也许我对“工作集”的定义不切实际）。
谢谢。
In my Windows XP Task Manager, some processes display a higher value in the Mem Usage column than the VMSize. My Firefox instance, for example shows 111544 K as mem usage and 100576 K as VMSize.
According to the help file of Task Manager Mem Usage is the working set of the process and VMSize is the committed memory in the Virtual address space.
My question is, if the number of committed pages for a process is A and the number of pages in physical memory for the same process is B, shouldn't it always be B ≤ A? Isn't the number of pages in physical memory per process a subset of the committed pages?
Or is this something to do with sharing of memory among processes? Please explain. (Perhaps my definition of 'Working Set' is off the mark).
Thanks.
发布评论
评论（6）
虚拟内存
假设您的程序（例如 Oracle）在启动时分配了 100 MB 内存 - 尽管没有触及任何其他物理/磁盘页面，但您的 VM 大小增加了 100 MB。 即VM只不过是内存簿记。
总可用物理内存+分页文件内存是系统中所有进程可以分配的最大内存。 系统这样做是为了确保在任何时候，如果进程实际开始消耗它分配的所有内存，操作系统都可以提供所需的实际物理页。
私有内存
如果程序将 10 MB 的数据复制到这 100 MB 中，操作系统会感知到没有页面分配给与这些地址对应的进程，并将 10 MB 的物理页分配到进程的私有内存中。 （这个过程称为页面错误）
工作集
定义：工作集是最近被程序触及的内存页面的集合。
此时，这 10 个页面已添加到进程的工作集中。 如果进程随后将此数据复制到先前分配的另一个 10 MB 缓存中，则其他所有内容都保持不变，但如果这些旧页面不在工作集中，则工作集会再次增加 10 Mb。 但是，如果这些页面已经在工作集中，那么一切都很好，并且程序工作集保持不变。
工作集行为
想象一下，您的进程再也不会触及前 10 页，在这种情况下，这些页面将从进程的工作集中修剪掉，并可能发送到页面文件，以便操作系统可以引入其他页面使用频率较高的页面。 然而，如果没有紧急的低内存需求，则不需要进行这种分页行为，操作系统可以表现得好像内存丰富。 在这种情况下，工作集只是保留这些页面。
工作时间是什么时候> 虚拟内存
现在想象一下同一个程序取消分配所有 100 Mb 内存。 程序 VM 大小立即减少 100 MB（记住 VM = 所有内存分配请求的簿记）
工作集不需要受此影响，因为这不会改变最近触及的那些 10 Mb 页面的事实。 因此，尽管操作系统可以在需要时回收它们，但这些页面仍然保留在进程的工作集中。
这将有效地使 VM < 工作集。 但是，如果您启动另一个消耗更多内存的进程并且工作集页面被操作系统回收，这将得到纠正。
Virtual Memory
Assume that your program (eg Oracle) allocated 100 MB of memory upon startup - your VM size goes up by 100 MB though no additional physical / disk pages are touched. ie VM is nothing but memory book keeping.
The total available physical memory + paging file memory is the maximum memory that ALL the processes in the system can allocate. The system does this so that it can ensure that at any point time if the processes actually start consuming all that memory it allocated the OS can supply the actual physical pages required.
Private Memory
If the program copies 10 MB of data into that 100 MB, OS senses that no pages have been allocated to the process corresponding to those addresses and assigns 10 MB worth of physical pages into your process's private memory. (This process is called page fault)
Working Set
Definition : Working set is the set of memory pages that have been recently touched by a program.
At this point these 10 pages are added to the working set of the process. If the process then goes and copies this data into another 10 MB cache previously allocated, everything else remains the same but the Working Set goes up again by 10 Mb if those old pages where not in the working set. But if those pages where already in the working set, then everything is good and the programs working set remains the same.
Working Set behaviour
Imagine your process never touches the first 10 pages ever again, in which case these pages are trimmed off from your process's working set and possibly sent to the page file so that the OS can bring in other pages that are more frequently used. However if there are no urgent low memory requirements, then this act of paging need not be done and OS can act as if its rich in memory. In this case the working set simply lets these pages remain.
When is Working Set > Virtual Memory
Now imagine the same program de-allocates all the 100 Mb of memory. The programs VM size is immediately reduced by 100 MB (remember VM = book keeping of all memory allocation requests)
The working set need not be affected by this, since that doesn't change the fact that those 10 Mb worth of pages where recently touched. Therefore those pages still remain in the working set of the process though the OS can reclaim them whenever it requires.
This would effectively make the VM < working set. However this will rectify if you start another process that consumes more memory and the working set pages are reclaimed by the OS.
XP 的任务管理器根本就是错误的。 编辑：如果您不相信我（有人不相信，因为他们否决了这一点），请阅读 Firefox 3 内存使用。 我引用：
听起来 MS 很困惑。 如果它坏了，你只能改变类似的东西。
请尝试使用 Process Explorer。 任务管理器标记为“VM 大小”，Process Explorer（更正确地）标记为“私有字节”。 在 Process Explorer 中，工作集（和专用字节）始终小于或等于虚拟大小，正如您所期望的那样。
XP's Task Manager is simply wrong. EDIT: If you don't believe me (and someone doesn't, because they voted this down), read Firefox 3 Memory Usage. I quote:
Sounds like MS got confused. You only change something like that if it's broken.
Try Process Explorer instead. What Task Manager labels "VM Size", Process Explorer (more correctly) labels "Private Bytes". And in Process Explorer, Working Set (and Private Bytes) are always less than or equal to Virtual Size, as you would expect.
文件映射
Mem 使用率高于 VM Size 的最常见方法是使用文件映射对象（因此它可以与共享内存相关，因为文件映射用于共享内存）。 通过文件映射，您可以拥有已提交的内存（无论是在页面文件中还是在物理内存中，您不知道），但没有为其分配虚拟地址。 已提交的内存显示在“内存使用情况”中，而已使用的虚拟地址使用情况则通过“虚拟机大小”进行跟踪。
另请参阅：
“虚拟机大小”是什么意思在 Windows 任务管理器中？ 在 Stackoverflow
打破 32 位障碍
仍然困惑为什么工作集大于虚拟内存
File mapping
Very common way how Mem Usage can be higher than VM Size is by using file mapping objects (hence it can be related to shared memory, as file mapping is used to share memory). With file mapping you can have a memory which is committed (either in page file or in physical memory, you do not know), but has no virtual address assigned to it. The committed memory appears in Mem Usage, while used virtual addresses usage is tracked by VM Size.
See also:
What does “VM Size” mean in the Windows Task Manager? on Stackoverflow
Breaking the 32 bit Barrier in my developer blog
Usenet discussion Still confused why working set larger than virtual memory
内存使用量是当前分配给进程的电子内存量。
VM Size 是当前分配给进程的虚拟内存量。
所以...
一些例子来说明：
目前在我的机器上，iexplore 有 16,000K 内存使用量和 194,916 VM 大小。 这意味着 Internet Explorer 使用的大部分内存处于空闲状态并已换出到磁盘，只有一小部分保留在主内存中。
与 mcshield.exe 相比，其内存使用量为 98,984K，VM 大小为 98,168K。 我的结论是 McAfee AntiVirus 处于活动状态，并且使用了大量内存。 由于它已经运行了相当长的一段时间（自启动以来一整天），我预计 98,168K VM 大小的大部分都是电子内存的副本 - 尽管任务管理器中没有任何内容可以证实这一点。
Memory usage is the amount of electronic memory currently allocated to the process.
VM Size is the amount of virtual memory currently allocated to the process.
so ...
Some examples to illustrate:
Currently on my machine, iexplore has 16,000K Memory Usage and 194,916 VM Size. This means that most of the memory used by Internet Explorer is idle and has been swapped out to disk, and only a fraction is being kept in main memory.
Contrast with mcshield.exe with has 98,984K memory usage and 98,168K VM Size. My conclusion here is that McAfee AntiVirus is active, with at lot of memory in use. Since it's been running for quite some time (all day, since booting), I expect that most of the 98,168K VM Size is copies of the electronic memory - though there's nothing in Task Manager to confirm this.
您可能会在内存中找到一些解释Shell Game
工作集 (A) – 这是进程的一组虚拟内存页面（已提交），位于物理 RAM 中。 这些页面完全属于该进程。 工作集就像“当前/最近在这些页面上工作”列表。
虚拟内存 – 这是操作系统可以寻址的内存。 无论物理 RAM 或硬盘空间的大小如何，该数字都受到处理器架构的限制。
提交内存 – 当应用程序接触虚拟内存页面（读/写/以编程方式提交）时，该页面将成为提交页面。 它现在由物理内存页支持。 这通常是物理 RAM 页面，但最终可能是硬盘上页面文件中的页面，也可能是硬盘上内存映射文件中的页面。 内存管理器处理从虚拟内存页到物理页的转换。 虚拟页面可能位于物理 RAM 中，而其旁边的页面可能位于硬盘驱动器上的页面文件中。
但是：PF（页面文件）使用情况 - 这是系统上已提交页面的总数。 它不会告诉您实际有多少内容写入页面文件。 它仅告诉您如果所有提交的页面必须同时写出到页面文件，则将使用多少页面文件。
因此B＞ A...
如果我们同意 B 代表“mem 使用”或 PF 使用，那么问题来自于它实际上代表 潜在页面使用：在 Xp 中，这个潜在的文件空间可以用作分配那些虚拟内存页面的地方程序已要求但从未投入使用......
You might find some explaination in The Memory Shell Game
Working Set (A) – This is a set of virtual memory pages (that are committed) for a process and are located in physical RAM. These pages fully belong to the process. A working set is like a "currently/recently working on these pages" list.
Virtual Memory – This is a memory that an operating system can address. Regardless of the amount of physical RAM or hard drive space, this number is limited by your processor architecture.
Committed Memory – When an application touches a virtual memory page (reads/write/programmatically commits) the page becomes a committed page. It is now backed by a physical memory page. This will usually be a physical RAM page, but could eventually be a page in the page file on the hard disk, or it could be a page in a memory mapped file on the hard disk. The memory manager handles the translations from the virtual memory page to the physical page. A virtual page could be in located in physical RAM, while the page next to it could be on the hard drive in the page file.
BUT: PF (Page File) Usage - This is the total number of committed pages on the system. It does not tell you how many are actually written to the page file. It only tells you how much of the page file would be used if all committed pages had to be written out to the page file at the same time.
Hence B > A...
If we agree that B represents "mem usage" or also PF usage, the problem comes from the fact it actually represents potential page usages: in Xp, this potential file space can be used as a place to assign those virtual memory pages that programs have asked for, but never brought into use...
内存碎片大概是这个原因：
如果进程分配 1 个八位字节，则它在 VMSize 中计为 1 个八位字节，但这 1 个八位字节需要一个物理页（在 Windows 操作系统上为 4K）。
如果在分配/释放内存后，进程有第二个八位位组与第一个八位位组相距超过 4K，则第二个八位位组将始终存储在与第 1 个八位位组不同的物理页上。
因此，VM 大小计数为 2 个八位字节，但内存使用量为 2 页== 8K
因此，MemUsage 大于 VMSize 的事实表明进程进行了大量分配和释放，并对内存进行了碎片化。
这可能是因为该过程很久以前就开始了。
否则还有优化的地方;-)
Memory fragmentation is probably the reason:
If the process allocates 1 octet, it counts for 1 octet in the VMSize, but this 1 octet requires a physical page (4K on windows operating system).
If after allocating/freeing memory, the process has a second octet that is separated by more than 4K from the first one, this second octet will always be stored on a separate physical page than the 1 one.
So the VM Size count is 2 octets but the Memory Usage is 2 pages== 8K
So the fact that MemUsage is greater than VMSize shows that process does a lot of allocation and deallocation and fragments the memory.
This could be because the process is started a long time ago.
Or else there is place for optimization ;-)