views:

7221

answers:

7

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.

A: 

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...

VonC
The last part of your post does not imply B > A. Rather the opposite: if total number of committed pages for a process is A and of those in physical memory is B, despite what you said, VonC, B ≤ A because pages in physical memory can only be a subset of total committed pages.
Frederick
But the way 'Xp Task Manager' reports them, B "the memory usage", is not just the physical memory, but also page files on hard disk.
VonC
Oh. But the Task Manager help file says 'Mem Usage' is the working set, and if I'm not wrong, working set is limited to the pages in physical memory only. But even if what you say is correct, then B = A not B > A, because A is the total committed virtual memory: pages in RAM + pages in disk.
Frederick
+1  A: 

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 ...

  • A page that exists only electronically will increase only Memory Usage.
  • A page that exists only on disk will increase only VM Size.
  • A page that exists both in memory and on disk will increase both.

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.

Bevan
+1  A: 

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:

If you’re looking at Memory Usage under Windows XP, your numbers aren’t going to be so great. The reason: Microsoft changed the meaning of “private bytes” between XP and Vista (for the better).

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.

Hugh Allen
I think its being wrong is unlikely, because it's so well known and commonly-used. Instead, perhaps I'm just confusing the definition of those terms.
Frederick
You're not confusing the terms. I've edited my answer to give more info.
Hugh Allen
+9  A: 

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.

Yep. The fact that OS lets freed up pages to hang around in the physical memory sounds like a good explanation of this phenomenon.
Frederick
Although, I don't think 'allocation' of 100 MB immediately leads to VMSize increase of 100MB. At least in Windows, that 100MBy will be marked "Reserved" first. When you write your 10MB somewhere into that 100MB then that 10MB will be marked "Committed" and VMSize incremented by 10MB (not 100).
Frederick
I think what you desribe in "When is Working Set > Virtual Memory" is wrong, with the only exception, and that is when you unmap file mapped pages. Otherwise the system knows the process has no longer any way how use the pages again and decommits them.
Suma
Ran some tests - allocated 100MB and both mem + VM went up. Uponw riting to just 10 Mb the mem usage dropped to 10M
When i allocated 1024 MB VM size was at 1024 Mb but mem usage stayed at some arbitrary value of 35 MB or so. Writing to 10MB after this did not increase Mem usage since Mem usage had already included the first 10MB i suppose.
In conclusion i would say that what amount of the allocated memory gets tagged to real pages and translates into memory size / working set depends on situation to situation and the OS in question. But overall the concept / differentiation between VM size and working set is as i have described.
Damn Windows and Microsoft. They don't tell us how they allocate memory and we need to run such blind tests to find out. May be we should seriously consider open source.
Faiz
+1  A: 

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

Suma
A: 

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 ;-)

Didier
A: 

In xp, I set the VM Size column, and every couple days it is gone from the taskmgr. How to make it stick please.

Jeannie
Jeanie,You'll be better off asking this as a separate question rather than writing here because all these are the answers to the question on the top.Also, your question belongs more to www.superuser.com than this site. Asking there is more likely to fetch you answers.
Frederick