Committed Bytes and Commit Limit - Memory Statistics

Question

I'm trying to understand the actual difference between committed bytes and commit limit. From the definitions below,

Commit Limit is the amount of virtual memory that can be committed without having to extend the paging file(s). It is measured in bytes. Committed memory is the physical memory which has space reserved on the disk paging files.

Committed Bytes is the amount of committed virtual memory, in bytes.

From my computer configurations, i see that my Physical Memory is 1991 MB, Virtual Memory (total paging file for all files) is 1991 MB and Minimum Allowed is 16 MB, Recommended is 2986 MB and Currently Allocated is 1991 MB.

But when i open my perfmon and monitor Committed Bytes and Commit Limit, the numbers differ a lot. So what exactly are these Committed Bytes and Commit Limit and how do they form.

Right now in my perfmon, Committed Bytes is running at 3041 MB (Sometimes it goes to 4000 MB as well), Commit Limit is 4177 MB. So how are they calculated. Kindly explain. I've read a lot of documents but I wasn't understanding how this works.

Please help. Thanks.

Solution

Commit limit is RAM size (not free RAM, total RAM usable by the OS) plus current pagefile size.

This is the maximum amount of "private committed" virtual memory that can exist on your system. Briefly, "private committed" virtual memory is virtual memory for which the pagefile is the "backing store". Meaning that if it can't all be kept in RAM, what can't be kept in RAM has to be in the pagefile, because there's no other place for it.

Committed Bytes, aka "commit charge", is mostly the total of all currently allocated private committed memory, plus the nonpaged allocations mentioned in the next paragraph.

Other types of virtual memory are either backed by other files (mapped files) - i.e. they come with their own backing store, so they don't contribute to commit charge - or must stay in RAM at all times (examples: Nonpaged pool; AWE allocations). These do contribute to commit charge.

In PerfMon, each process's "Private bytes" counter is its "committed bytes" allocation. i.e. its contribution to the system-wide "commit charge". Paged pool is counted as "committed bytes" also - it has to be in RAM or in the pagefile. Nonpaged pool, AWE allocations, and other nonpageable things are also counted as "committed bytes" (despite that they never go to the pagefile) so that the amount of "commit limit" remaining is properly counted for. These are the major contributors to "committed bytes."

Running out of commit limit is the reason you see "system is low on memory" or "system is out of memory" messages. (They're not about free RAM!) In the former case the OS has expanded your pagefile - thus increasing the commit limit - to make room for the new allocations. In the latter it's already done that as much as it can (within your current pagefile settings) and someone still wants more.

For more, see a few other of my answers: the "bank analogy", a really long one, and another one.