The most important element about the paging file is how it impacts a particular aspect of the system, with that aspect being the system commit limit. When processes allocate certain types of virtual memory, the allocation is charged against something known as the system commit limit. The commit limit represents the maximum amount of virtual memory, which has to be backed by physical memory or the paging file, processes can allocate at any one time. The limit is therefore derived from the sum of physical memory (or most of), plus the size of the paging file(s).
You can monitor the system committed virtual memory utilisation of the system by using a tool like
Process Explorer. The information will be shown under the 'Commit Charge (K)' section of the 'Memory' tab.
Commit Charge (K):
- Current - This represents the amount of committed virtual memory processes have currently allocated which must be backed by physical memory or stored in the paging file.
- Limit - This represents the amount of committed virtual memory processes can allocate at any one time and is the sum of most of physical memory and the size of the paging file(s).
- Peak - This represents the total amount of committed virtual memory processes have allocated since the system booted which must be backed by physical memory or stored in the paging file.
The system commit limit has to be large enough to support the system committed virtual memory requirements of the workload which you're running. If the commit limit is smaller than that value, your processes won't be able to allocate the virtual memory they want and will fail to run correctly. I have illustrated what happens when you hit the system commit limit at the bottom of this post.
If you're going to manually size the paging file, once you feel you have attained your maximum workload, have a look at the 'Commit Charge Peak' value. The difference between that value and the amount of physical memory of the machine is how large the paging file will need to be on your system to support that particular workload. For example, if your workload requires 6GB of system commit and the machine has 4GB of physical memory, the paging file will need to be at least 2GB. This should be the bare minimum for the initial size of the paging file. You would want to add extra onto that value to give yourself some buffer. If you are interested in crash dumps, make sure it's large enough to accommodate them as well.
For the maximum, you could set it to double the initial size. Some people may suggest having the initial and maximum sizes the same to prevent the paging file from expanding and contracting. Assuming this is an issue, the paging file will only grow when the 'Commit Charge Current' reaches whatever the initial system commit limit is. Providing the initial allocation is sufficient, the paging file will never need to grow and the maximum simply serves as a safety net.
If the amount of physical memory you have exceeds the amount of system committed virtual memory your workload requires, you don't need a paging file and Windows will run perfectly fine without one. However, there are a couple of disadvantages of running with no paging file.
- The subset of pages on the modified page list which could get written out to the paging file will no longer be able too. This results in less memory being available for other purposes.
- The system won't be able to generate crash dump files. This also applies to cases where you have one, but isn't large enough to support the crash dump you are configured for.
---------------------------------------------------------------------------------------------
The following is just an illustration of what will happen in a best case scenario when you hit the system commit limit. The system which I was using had 4GB of physical memory and both the initial and maximum size of the paging file had been set to 1024MB.
