*** A Pagefile Discussion ***

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.
  • Hard page faults still occur.
  • How Windows manages physical memory.
To address the first point. Things like exe's and dll's are backed by their own location on disk, not the paging file. *** In the process of rewriting this section *** All that happens when you disable the paging file is the things that could get written there, the scenario where the data is written and read back in from disk is taken out of play.

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.

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 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:
I have run a test on my own system to illustrate what happens when you hit the system commit limit. My system has 4GB of physical memory and the initial and maximum size of the paging file has been set to 2GB, which means the system commit limit is roughly 6GB. I ran a tool called Testlimit and directed it to allocate 4GB of private committed virtual memory by using the -m switch. As I reached the system commit limit, my processes were unable to allocate the virtual memory they wanted and Windows popped up a message telling me I was low on memory.

If you do ever hit the system commit limit on your own system, there is no guarantee that Windows is going to respond to hitting the limit quite as nicely as highlighted in the image below. In fact, I had to run this test several times to get Windows to pop up the "Your computer is low on memory" message. The first few times when I hit the system commit limit, I experienced a system wide crash which forced me to restart the entire machine.

If you are managing the paging file yourself and have set a larger maximum than the initial size, or you are letting Windows manage it, the paging file will grow when the amount of system committed virtual memory which has been allocated nears the initial system commit limit, which means the system commit limit will also grow. The system commit limit will grow right up and till the paging file has hit it's maximum size, assuming there is a demand for it, of course.

ProcessExplorerv1.png


ProcessExplorerv2.png


-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Videos:




Papers:


 
I'd be interested in the TL;DR too :p

I have a machine with 48GB of RAM, and having skim read the above, I am still not sure how much the page file should be set too.
IIRC it is not set at the 40-60GB that windows was recommending, I think I set it to 6GB and i've not had any issues (and recovered the SSD space!)

It does surprise me that windows doesn't natively cap it, I had a play with a four socket X7500 server with 512GB of RAM over the summer and windows was recommending the same (EDIT: it was requesting 192GB, the max W7x64 can see, it booted RHEL usually) for the page file, but had only allocated ~2 gig on its first boot.
 
Very interesting and thorough read (most of it went over my head!)

From the read you can see there is apparent optimum, but is there a good general rule of thumb.

I feel in my machine I don't really utilise all the RAM I have (8GB). I run Windows 7 x64 and have at most Football Manager, Photoshop (with a couple of images) and a Virtual Machine (1GB) and most of the time I will only have one open at once. I've left the PageFile to Windows to manage and now wonder how its doing.
 
Unless you are on an SSD or your system volume is low on space, I wouldn't bother with anything other than system managed. If this is a problem for you, you need to know how much RAM you use, which the last bit of FW's post shows how to measure. From that you can decide what size is best for you.
 
Interesting read thanks. Only digested the first half but will read the rest later.

Hypothetical scenario, say you are running a desktop pc, with a moderate amount of ram, say 4-8gigs, and your running a fairly heavy workload for a home system, I dunno, like playing a demanding game whilst encoding a blu ray, and streaming a different blue ray to another device..... assuming its all happening on the system drive... one drive, the system drive..

Would there be any benefits in having a massive page file over a system manager one? assuming you have buckets of free space.... say something daft like a 50gb page file... Obviously the drive i/o would be crippled anyway but this is hypothetical :D
 
What's the TLDR on this, leave it set as system managed? :)

From the read you can see there is apparent optimum, but is there a good general rule of thumb.

If there is going to be a general rule of thumb regarding sizing the paging file, it would probably be to just let Windows manage it. While Windows may not size the paging file in the most appropriate way due to the formula which it uses, it is sufficient in the sense that it should be able to support the system committed virtual memory requirements of 99.99% of workloads.

I feel in my machine I don't really utilise all the RAM I have (8GB). I run Windows 7 x64 and have at most Football Manager, Photoshop (with a couple of images) and a Virtual Machine (1GB) and most of the time I will only have one open at once. I've left the PageFile to Windows to manage and now wonder how its doing.

If you are interested in seeing how large the paging file needs to be to support your workload, you will need to monitor how much system commit your workload requires.

*Snip*

Would there be any benefits in having a massive page file over a system manager one? assuming you have buckets of free space.... say something daft like a 50gb page file... Obviously the drive i/o would be crippled anyway but this is hypothetical :D

Assuming the size of the paging file which Windows allocates is large enough to support your workload, there shouldn't be any benefit in increasing the size of the paging file beyond that.
 
Last edited:
If you are interested in seeing how large the paging file needs to be to support your workload, you will need to monitor how much system commit your workload requires.

Interesting, now it was I was consider to be an intensive time for me and my commit is: 3866 /8050.

I think I may try without a Page File for a while and see what happens.

Thanks.

(If anything, this post was a bump because I think its an interesting topic)
 
Back
Top Bottom