A common recommendation is to make the page file 1.5 times the size of the installed RAM. This recommendation makes sense only for computers with small amounts of RAM (256 MB or less). For example, there is usually not much point in allocating a page file that is 3 GB if the computer has 2 GB of RAM.
Quite the contrary, one should definately do that, at least if it is possible for the commit charge to reach over 2GB.
The objective in such RAM rich systems is to avoid using the pagefile at all by providing sufficient RAM that all virtual memory can be in RAM all the time. If the virtual memory in use exceeds the amount of installed RAM, performance will suffer and having a larger pagefile will not help this situation.
Again, that presumes a "spillover" model, which NT's VM/paging is not. Indeed, if "virtual memory in use" exceeds the amount of installed RAM - why by golly, that's why we have pageable VM systems in the first place! And if you followed the previous advice in that note, you would be screwed, because you would be out of (virtual) memory. But not if you followed the advice to allocate 1.5x-2x pagefile space compared to physical RAM.
In fact, let's consider the performance issues, if you have a 3GB pagefile, 2GB of RAM, and a task that accesses a number of large on-disk files, and has a large (1GB, say) set of initialization data, that is only used at startup and rarely thereafter.
You will get maximum overall performance, likely, by writing out that 1GB worth of startup data to the pagefile, and then you have an additional 1GB worth of physical RAM to use for filesystem caching for loading those large files for processing.
A contrived example, certainly, but it simply tries to point out that keeping stale pages in physical RAM is ... no different than wasted RAM. Paging out to disk turns "wasted" pages into "available" pages - that's a good thing, and why a pagefile can *increase* performance in the long run! (Also why setting DisablePagingExecutive is also not a performance benefit in most cases.)
However, increasing the size of the filesystem cache, like any cache, reaches a point of diminishing returns. NT does seem to have a bit of a problem being over-zealous in paging out active applications just to free up RAM to add to the filesystem cache. On a server, where disk access patterns approach random, more disk cache is a good thing, but on a desktop where most I/O tasks are sequential and/or localized, there is a bit less benefit from growing the filesystem cache to huge proportions. There is also a need for higher interactive latency on desktops.
Another thing that may be overlooked - ATI's video drivers store various things in pagable system RAM, so if something is paging madly trying to re-draw - it may be the video drivers directly, and not the fault of the OS at all.
