You have arrived here because you have identified a high system commit usage condition. If this is not correct, then return to the Start of the Performance Guide.

System committed memory

The system commit limit of Windows and Windows Server is the sum of physical memory and the size of all of the page files combined on the system. It is the maximum amount of physical resources that the system can use to back committed memory. It is a factitious resource that prevents the system from over committing or over "promising" too much physical resources. With that said, when the system is unable to commit anymore memory, then applications may fail to function and the system may hang indefinitely.

The System Commit Charge is the total amount of memory used/committed by the operating system and all processes running on the computer. This memory is considered "in use", but does not mean that the memory has been written to or "touched". This means that it is possible that the system commit charge can reach the system commit limit, but still have plenty of available physical memory and plenty of free space on the paging files.

 

The above screenshot is of Windows Task Manager on Windows 7. Highlighted in red is the System Commit Charge (2074 MB) and the System Commit Limit (8058 MB).

If the System Commit Charge reaches the System Commit Limit, then the system will attempt to increase the page file size (if set to System Managed), otherwise, the system will be in an out of memory condition. The percentage of the System Commit Charge compared to the System Commit Limit can be measured using the "\Memory\% Committed Bytes In use" performance counter.

Process Committed Memory

Processes operate in virtual memory and are unaware of the true physical environment of the computer, but when an application "commits" memory, then the operating system guarantees physical resources (physical memory and paging files) will back the allocation. When the application writes to memory such as writing a value to a variable, then the memory is mapped to physical memory.

Windows - Virtual Memory Minimum Too Low

When the Windows operating system reports that it is low on "virtual memory" and mentions increasing the paging file, then it means that the System Commit Charge has reached the System Commit Limit. The paging file is commonly referred to as "virtual memory", hense this reference. Unfortunately, the concept of process and kernel virtual memory is an entirely different subject unrelated to the system commit limit.

 

Troubleshooting

If the "\Memory\% Committed Bytes In use" performance counter is over 75%, then the system is close to running out of memory (both RAM and all page files). To troubleshoot this issue, try to find the highest consumers of committed memory:

1. Identify which processes are consuming the most committed memory: The “Private Bytes” of a process is the amount of private committed memory (process heap memory) within a process. Look at “\Process(*)\Private Bytes” to see which processes are consuming the most and which are on an increasing trend over a long period of time. Keep in mind that Private Bytes is potential pagable memory and cannot be measured by looking at just physical memory usage (Working Set) alone. If you have identified processes consuming significant amounts of committed memory, then go here. [Link to future article]
2. Kernel pool memory: Drivers store their memory into the kernel memory pools Paged Pool and Nonpaged Pool. The memory in both of these pools is charged against the system commit charge. The memory usage of these pools are shown in the Performance tab of Task Manager or by using the counters \Memory\Pool Paged Bytes and \Memory\Pool Nonpaged Bytes.
3. Driver locked memory: Drivers can lock memory and that memory will be charged to the system commit charge. An example of driver locked memory is the Hyper-V driver locking memory for a virtual machine. Driver locked memory can be shown using the Sysinternals tool RAMMap. Also, VMWare's memory "ballooning" will show up as Driver Locked.
4. System committed backed shared memory sections: An application can create a shared memory section and this memory allocation will add to the system commit charge immediately. As the process(es) use the shared memory, that memory will be mapped into their respective virtual address spaces, but if the shared memory is allocated, but not used, then it is nearly impossible to identify which process created it. Since there is no owner to look up, thounters \Memory\Pool Paged Bytes and \Memory\Pool Nonpaged Bytes.
5. Driver locked memory: Drivers can lock memory and that memory will be charged to the system commit charge. An example of driver locked memory is the Hyper-V driver locking memory for a virtual machine. Driver locked memory can be shown using the Sysinternals tool RAMMap. Also, VMWare&#e Sysinternals tools VMMap, RAMMap, and Process Explorer cannot show any further details. With that said, kernel debugging will show the existence of this resource as "Shared Commit" in the output of "!vm".
6. Kernel debugging: Use the Windows Debugger (WinDBG) to attach to the kernel and do a "!vm" command. This will show other memory areas that count towards the system commit charge such as shared committed, session committed memory and driver committed.

Treating the Symptoms

If all of the above troubleshooting steps have been exhausted, then the symptoms of a high system commit charge can be treated with one or more of the following:

1. Add physical memory: More physical memory will increase the system commit limit. If the system is low on committed memory, the dynamic memory feature of Hyper-V can add physical memory to a virtual machine while the virtual machine is still running.
2. Add or increase the size of page files: When the computer is low on committed memory, it will try to increase the size of the page file if it has not yet reached its maximum size. System managed paging files will increase up to three times physical memory or 4 GB whichever is larger.
3. Avoid “Memory Optimizers”: Windows is very efficient at managing memory. So called, “memory optimizers” simply force the kernel to delete its disk cache and trim the working sets (more paging) of processes. All this does is cause a lot of unnecessary disk I/O.

More Information

Vital Signs Workshop: Microsoft Services offers an instructor led workshop called, "Vital Signs", which goes in depth into Windows architecture focused on Windows performance analysis. If you are interested, then contact your Microsoft Technical Account Manager (TAM). If you do not have a Microsoft Premier Support contract, then consider the great benefits of having one by going to our Microsoft Services Premier Support web site at: http://www.microsoft.com/microsoftservices/en/us/support_premier.aspx