What is the real virtual memory of the operating system? (3. Committed memory)

1. Commit limit and current commit charge

Next, we can see that the testlimit-r switch only reserves the virtual memory and does not actually commit (COMMIT ). Reserved virtual storage does not store data or code, but sometimes the application requires this reserved space (just like the reserved space) to create a large volume of virtual storage and submit it as needed, to ensure that the submitted address space is continuous. When a process commits a virtual memory, the operating system must ensure that the data stored in the memory is either in the memory or in the hard disk. This means that the process has another limit: commit limit.

Commit limit is the sum of physical memory and page file size. In fact, not all physical memory is counted, because the operating system reserves a part for itself. The total number of VMS submitted by all surviving processes is called current commit charge, which cannot exceed the system's commit limit. When the commit limit value is reached, the allocation of virtual storage will fail. This means that the Standard 32-bit process may fail to allocate virtual memory before it reaches the 2 GB address space limit.

Current commit charge and commit limit are tracked by the Process Manager. Their data is displayed as follows:

In versions earlier than Vista and win2008, the current commit charge and limit may not be displayed, but the current commit change ("pf usage") is used, which is actually the page File Usage:

In Vista and win2008, the task manager does not display the commit charge graph. Only the current commit charge and limit values are given, which are expressed as "page file"

You can use testlimit-m to perform a stress test on the commit limit to forcibly allocate committed memory. The 32-bit version of testlimit may not experience the level limit of the address space until it reaches the commit limit. This depends on the size of the physical memory, the size of the file on the VM page, and the size of the current commit charge value. If you are running in 32-bit windows and want to see the behavior of the system when the commit limit is reached, you can run several more testlimit instances until one reaches the commit limit before the address space is exhausted.

Note that by default, page files are dynamically increasing, which means that commit limit will also grow dynamically (when commit charge grows closer to it), and, even if the page file reaches its maximum value, the system will release part of the memory for internal adjustment, just as some of the memory will be released after normal applications cache data. After reaching the commit limit, testlimit will sleep for several seconds, and then tries to allocate more memory and repeat it until it is forcibly terminated.

If you are running a 64-bit testlimit, it is almost certainly that before the address space is exhausted, it will reach the commit limit, unless the physical memory and page file size can exceed 8 TB, this 8 TB is described in Section 1, which is the address space that can be accessed by 64-bit applications. Here is part of the result of 64-bit testlimit running on an 8 GB Memory System (100 MB for each allocation: