Process Explorer: What does the Commit History graph show?

Question

In the Memory graph available in Process Explorer, the top graph shows Commit History. What does this actually indicate at the OS level?

To experiment if this is the memory allocated on the heap by a process, I wrote a small program that incrementally malloc-ed 100 MB many times. The Commit History graph increased for a while (upto 1.7 GB of memory allocation) and did not grow after that despite the program malloc-ing memory.

So, what is this graph indicating? How can this information be used to understand/analyse the state of Windows?

Answer 1

The Commit level is the amount of anonymous virtual address space allocated to all processes in the system. (It does not include any file-backed virtual address space, e.g., from an mmap'd file.) In process explorer, the 'Commit History' graph shows the size of this value over time.

Because of the way virtual memory is allocated and parceled out (the actual RAM backing a page of virtual address space isn't necessarily allocated until its first touched), this current 'commit' level represents the worst case (at the moment) of memory that the system may have to come up with. Unlike Linux, Windows will not hand out promises (address space) for RAM it cannot come up with or fake (via the paging file). So, once the commit level reaches the limit for the system (roughly RAM + pageing file size), new address space allocations will fail (but new uses of existing virtual address space regions will not fail).

Some conclusions about your system that you can draw from this value:

• If this value is less than your current RAM (excepting the kernel and system overhead), then your system is very unlikely to swap (use the paging file) since in the worst case, everything should fit in memory.
• If this value is much larger than physical memory usage, then some program is allocating a lot of virtual address space, but isn't yet using it.
• Exiting an application should reduce the committed memory usage as all of its virtual address space will be cleaned up.

Your experiment validated this. I suspect you ran into address space limitations (32-bit processes in windows are limited to 2GB ... maybe 300MB disappeared to fragmentation, libraries and text?).