Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
The paging file is an interesting subject and one which is fairly misunderstood. Many people are under the impression that the paging file is there to support the user when they have run out of physical memory. This isn't correct. The purpose of the paging file is so the system can write pages on the modified page list, which represent pages that have been taken out of a process working set because they aren't being accessed actively but have not yet been saved to disk, out to the paging file. This results in that memory being available for much more useful purposes, such as caching, for instance.
The argument that is frequently used as to why you should disable the paging file is because hard disks are slower than memory. This ignores the following two points.
Touching upon the second point. If a page is dropped from a working set which has been modified, it is moved to the modified page list. When the modified page list reaches a threshold, a thread called the ModifiedPageWriter wakes up and begins writing pages out to the paging file. The pages are then immediately moved to the standby page list, where they can be soft page faulted back into the process working set. It's only when the memory manager gives the page which belonged to the original process to someone else will it have to retrieve it's data from the paging file. If it gets to this point, the fact the process needs to read from the paging file is going to cause a negligible impact on system performance. If that data was in your performance interest, it would already be resident in memory.
A question which is frequently asked about the paging file is; How big does the paging file need to be? There seems to be a lot of misinformation around this and many of the recommendations advice you to size the paging file by multiplying the amount of physical memory of the machine by some random number, normally within the range off 1.5 ~ 2.5. Also, even though a lot of people recommend doing so, letting Windows manage the size of the paging file doesn't make much sense either because it also sizes it based on the amount of physical memory of the machine. Windows manages the size of the paging by using the following formula; If you have less than 1GB of RAM, the initial size is 1.5x RAM, otherwise it's the size of RAM, and in both cases, the maximum size is three times RAM or 4GB, depending on which one is larger.
The reason why these recommendations don't make a great deal of sense is because physical memory isn't the only resource which needs to be taken into consideration when determining the size of the paging file. The other resource which needs to be taken into account is the amount of committed virtual memory, which must be backed by physical memory or stored in the paging file i.e. system commit, processes allocate for a specific workload. To find out how much system commit your workload requires, download Process Explorer from Sysinternals. Once Process Explorer is running, open the "System Information" window by either clicking on one of the graphs at the top or by pressing Ctrl + I, and then click on the "Memory" tab. There will be a label called "Commit Charge (K)" followed by the following three counters.
The system commit limit needs to be large enough to support the system committed virtual memory requirements of a particular workload. If the system commit limit is smaller than that requirement, processes won't be able to allocate the virtual memory they want and will fail to run correctly, which I have illustrated in my second post here.
If you would like to size the paging file yourself, load up your most demanding workload and then look at the commit charge peak. The difference between that value and the amount of physical memory of the machine is the size of the paging file which you will need to support your workload. For example, if your machine has 4GB of physical memory and your most demanding workload requires 4.8GB of system commit, you would need a paging file of at least 800MB to support that particular workload. This should be the bare minimum for the initial size of the paging file. You would ideally want to add a little extra onto that value so you have plenty of breathing room. If you're interested in crash dumps, make sure it's larger enough to hold them as well.
Another question which is quite often asked is; Do you even need a paging file? There seems to be a myth that Windows actually requires a paging file to function correctly. If you consider the purpose of the paging file, which is so the system can write modified pages out to disk. If the system doesn't have a paging file, those pages have to be backed by physical memory. While this will result in less memory being available for other purposes, it's not going to prevent Windows from functioning correctly. Though, it is worth taking into account the system won't be able to generate crash dumps if there is no paging file.
Does that mean if you are happy with the disadvantages highlighted above, you can disable the paging file without any issues? Nope, not necessarily. It doesn't take into account how much system commit your workload requires. If we assume you have enough physical memory to support the system committed virtual memory requirements off your workload, you don't need a paging file and Windows will run just fine without one under that particular workload. For example, you have an 8GB machine and your most demanding workload requires no more than 5GB of system commit.
Edit - I'm in the process of rewriting sections of this post to make things a little clearer. It's a bit of a jumbled mess at the moment.
The argument that is frequently used as to why you should disable the paging file is because hard disks are slower than memory. This ignores the following two points.
- Hard page faults still occur.
- How Windows manages physical memory.
Touching upon the second point. If a page is dropped from a working set which has been modified, it is moved to the modified page list. When the modified page list reaches a threshold, a thread called the ModifiedPageWriter wakes up and begins writing pages out to the paging file. The pages are then immediately moved to the standby page list, where they can be soft page faulted back into the process working set. It's only when the memory manager gives the page which belonged to the original process to someone else will it have to retrieve it's data from the paging file. If it gets to this point, the fact the process needs to read from the paging file is going to cause a negligible impact on system performance. If that data was in your performance interest, it would already be resident in memory.
A question which is frequently asked about the paging file is; How big does the paging file need to be? There seems to be a lot of misinformation around this and many of the recommendations advice you to size the paging file by multiplying the amount of physical memory of the machine by some random number, normally within the range off 1.5 ~ 2.5. Also, even though a lot of people recommend doing so, letting Windows manage the size of the paging file doesn't make much sense either because it also sizes it based on the amount of physical memory of the machine. Windows manages the size of the paging by using the following formula; If you have less than 1GB of RAM, the initial size is 1.5x RAM, otherwise it's the size of RAM, and in both cases, the maximum size is three times RAM or 4GB, depending on which one is larger.
The reason why these recommendations don't make a great deal of sense is because physical memory isn't the only resource which needs to be taken into consideration when determining the size of the paging file. The other resource which needs to be taken into account is the amount of committed virtual memory, which must be backed by physical memory or stored in the paging file i.e. system commit, processes allocate for a specific workload. To find out how much system commit your workload requires, download Process Explorer from Sysinternals. Once Process Explorer is running, open the "System Information" window by either clicking on one of the graphs at the top or by pressing Ctrl + I, and then click on the "Memory" tab. There will be a label called "Commit Charge (K)" followed by the following three counters.
The system commit limit needs to be large enough to support the system committed virtual memory requirements of a particular workload. If the system commit limit is smaller than that requirement, processes won't be able to allocate the virtual memory they want and will fail to run correctly, which I have illustrated in my second post here.
If you would like to size the paging file yourself, load up your most demanding workload and then look at the commit charge peak. The difference between that value and the amount of physical memory of the machine is the size of the paging file which you will need to support your workload. For example, if your machine has 4GB of physical memory and your most demanding workload requires 4.8GB of system commit, you would need a paging file of at least 800MB to support that particular workload. This should be the bare minimum for the initial size of the paging file. You would ideally want to add a little extra onto that value so you have plenty of breathing room. If you're interested in crash dumps, make sure it's larger enough to hold them as well.
Another question which is quite often asked is; Do you even need a paging file? There seems to be a myth that Windows actually requires a paging file to function correctly. If you consider the purpose of the paging file, which is so the system can write modified pages out to disk. If the system doesn't have a paging file, those pages have to be backed by physical memory. While this will result in less memory being available for other purposes, it's not going to prevent Windows from functioning correctly. Though, it is worth taking into account the system won't be able to generate crash dumps if there is no paging file.
Does that mean if you are happy with the disadvantages highlighted above, you can disable the paging file without any issues? Nope, not necessarily. It doesn't take into account how much system commit your workload requires. If we assume you have enough physical memory to support the system committed virtual memory requirements off your workload, you don't need a paging file and Windows will run just fine without one under that particular workload. For example, you have an 8GB machine and your most demanding workload requires no more than 5GB of system commit.
Edit - I'm in the process of rewriting sections of this post to make things a little clearer. It's a bit of a jumbled mess at the moment.
Last edited:
