Commit charge
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
In computing, commit charge is a term used in Microsoft Windows operating systems to describe the total amount of virtual memory of all processes that must be backed by either physical memory or the page file.[1] Through the process of paging, the contents of this virtual memory may move between physical memory and the page file, but it cannot exceed the sum of sizes of those two. As a percentage, commit charge is the utilization of this limit.
Virtual memory not related to commit charge includes virtual memory backed by files and all-zero pages backed by nothing.
Overview
[edit]The Windows Task Manager utility for Windows XP and Server 2003, in its Performance tab, shows three counters related to commit charge:
- Total is the amount of pagefile-backed virtual address space in use, i.e., the current commit charge. This is composed of main memory (RAM) and disk (pagefiles). The corresponding performance counter is called "Committed Bytes".
- Limit is the maximum possible value for Total; it is the sum of the current pagefile size plus the physical memory available for pageable contents (this excludes RAM that is assigned to non-pageable areas). The corresponding performance counter is called "Commit Limit".
- Peak is the highest amount that the total commit charge has reached since the operating system was last started.
The program Process Explorer reports the same set of values, labeling the Total as Current, and additionally providing percentages of Peak and Current towards the Limit value.
The commit charge increases when any program is opened and used, and goes down when a program is closed. It will also change when already-running programs allocate or free private virtual memory; for example, with the VirtualAlloc and VirtualFree APIs.
In the Task Manager utility under Windows XP and Windows Server 2003, the graphical displays labeled as "PF usage" and "Page File Usage History," despite their labels, reflect not the pagefile contents but the total (or current) commit charge. The height of the graph area corresponds to the commit limit. These do not show how much has actually been written to the pagefile, but only the maximum potential pagefile usage: The amount of pagefile that would be used if all current contents of RAM had to be removed. In Windows 2000 and Windows NT 4.0, these same displays are labeled "Mem usage" but again actually show the commit charge and commit limit. Similar displays in the Task Manager of Windows Vista and later have been changed to reflect usage of physical memory.
In Task Manager's "Processes" display, each process's contribution to the "total commit charge" is shown in the "VM size" column in Windows XP and Server 2003. The same value is labeled "Commit size" in Windows Vista and later. The total commit charge will always be larger than the sum of these values, as the total includes system-wide allocations such as the paged pool.
In the same display, the "Mem Usage" column in Windows XP and Server 2003, or the "Working Set (Memory)" column in Windows Vista and later, shows each process's current working set. This is a count of physical memory (RAM) rather than virtual address space. It represents the subset of the process's virtual address space that is valid, meaning that it can be referenced without incurring a page fault.
The commit charge for each process does not include other major contributions to the process's virtual address space, such as mapped files. For this reason, the process's working set (the portion of its address space that can be referenced without incurring a page fault) may be larger than its contribution to total commit charge, and the total commit charge is not inclusive of the total memory (physical or virtual) actually in use.
The commit limit may be increased by either creating additional pagefiles or, if pagefile expansion is enabled, by expanding an existing one. The operating system will expand the pagefile automatically, if possible, when the total commit charge approaches the limit. In such an event a popup window will be displayed stating that "The system is running low on virtual memory."
If the system ever runs completely out of commit charge (that is, if the total reaches the limit), a popup window will be displayed stating that "The system is out of virtual memory," and it may become extremely sluggish or even nonresponsive. Closing programs (if the user is still able to do so at this point) decreases the total commit charge and may thereby free up the system.
See also
[edit]References
[edit]Cited references
[edit]- ^ Russinovich, Mark (17 November 2008). "Pushing the Limits of Windows: Virtual Memory". Mark's Blog. learn.microsoft.com. Archived from the original on 22 October 2022. Retrieved 15 December 2022.
Reserved virtual memory can't actually store data or code, but applications sometimes use a reservation to create a large block of virtual memory and then commit it as needed to ensure that the committed memory is contiguous in the address space. When a process commits a region of virtual memory, the operating system guarantees that it can maintain all the data the process stores in the memory either in physical memory or on disk.
Further reading
[edit]- Solomon, David A.; Russinovich, Mark E. (16 September 2000). Inside Microsoft Windows 2000. Microsoft Programming Series (Third ed.). Redmond, Washington: Microsoft Press. ISBN 978-0735610217. LCCN 00031888. OCLC 473864294. OL 7890737M. Retrieved 15 December 2022 – via Internet Archive.
- Russinovich, Mark E.; Solomon, David A. (8 December 2004). Microsoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 (Fourth ed.). Redmond, Washington: Microsoft Press. ISBN 978-0735619173. LCCN 2004115221. OCLC 799279133. OL 7891080M. Retrieved 15 December 2022 – via Internet Archive.
