When it comes to sizing the paging file, the most important thing to take into consideration is related to system commit. When processes allocate certain types of virtual memory, the allocation gets charged against the system commit limit. Windows is making you a commitment that it will be able to back that data by physical memory, or store it on disk in a paging file. The limit is therefore 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 your workloads system committed virtual memory requirements. If it isn't, 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 your workload. For example, if your workload requires 5.2GB of system commit and the machine has 4GB of physical memory, the paging file would have to be at least 1.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 whatever the initial size has been set as. 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 is simply there as a safety net.
If the amount of physical memory you have exceeds the amount of system commit 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 with 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.
---------------------------------------------------------------------------------------------
A few bits and pieces which you may find interesting regarding this subject.
Papers:
Videos: