Seems that many people around the world are clueless when it comes to the pagefile.

Just remember to stick to best practise rules and the pagefile will never worry you.

The first part of "best practice," is to set the default pagefile size so you never see the "system is running low on virtual memory" popup.

( For best performance there needs to be quite a bit of "margin" on this. The best way to judge this is the pagefile %usage counter in the Performance tool - you want this to not exceed 25%. Keeping the task manager "PF usage" meter to 50% or less is a reasonable alternative. Having a LOT of free space in the pagefile lets the pagefile allocation code happy. )

If you're into kernel debugging and doing full memory dumps the default size needs to be the size of RAM, plus perhaps a few tens of MBs. So your default size needs to be the larger of this value, or the size needed to keep the PF %usage below 25%. Most people are fine without full memory dumps.

The second part of "best practice" is then to set the maximum size to at least twice the default size. In fact there's actually no reason to set the maximum size to anything other than the max of 4 GB, unless of course the free space on the drive makes that pointless.

This gives you a completely free (I mean absolutely, utterly, no foolin', NO overhead whatsoever) safety net - just in case
your default size turns out to be too small someday.

Contrary to what many web sites will tell you, allowing pagefile expansion will NOT cause the system to spend time "managing" or "expanding and contracting" the pagefile... not unless it actually needs the expansion area.

It's also widely believed that allowing pagefile expansion will cause the pagefile to become fragmented. Reality is that if the pagefile never has to be expanded, it will stay in exactly the fragmentation state it's in forever. If expansion is necessary, this is done by simply allocating additional extents as needed. This does not affect the fragmentation of the original allocation for the pagefile's default size, and as soon as all "uses" of the expanded areas are gone, the additional extents are deleted. This takes very little time and, again, does not change the fragmentation of the original allocation.