Optimum Page File Size - SSD Raid 0 - Win 7 Pro x64 - 32GB ram

With the upcoming release of Middle-earth: Shadow of Mordor on Tuesday I have been going over my system making sure it is as optimized as I could get it.

I am looking for the best size for my systems page file. I use my system for gaming, as a HTPC, web browsing, torrent downloading/seeding and occasionally photo editing. I do a lot of multitasking, regularly at the end of the day I have 80+ tabs open across 5 - 8 windows, Spotify, uTorrent runs constantly in the background unless I am gaming. When I am gaming I usually close down all unnecessary tabs, close utorrent and anything else that I am not using; I will run Spotify and browse as needed.

Is it best to let windows manage the page file, which in my case creates a page file up to 48GB, or could I set the page file manually to a smaller size without a negative effect on my systems performance?

System Specs-
OS - Windows 7 Pro x64
CPU - Intel Core i7-3770K 4.2 GHz
Motherboard - Asus Sabertooth Z77
Ram - 32GB - x4 Crucial Ballistix 8GB DDR3
SSD - x2 SanDisk Extreme 120GB (Raid 0) - OS is on this array
GPU - EVGA GeForce GTX 670 FTW 2GB
Sound Card - Xonar Essence STX
Blu-ray - LITE-ON iHBS212-08
PSU - SeaSonic SS-750KM3 750W

I have a few regular hard drives ranging in size from 1 TB to 4TB, however I think it is better to have the page file on the SSD raid 0 array for the fast read and write times.

Agree with Gator, with 32GB RAM, the optimum size is effectively "disabled", unless you run tons of virtual machines at the same time or run a server out of your computer, but for normal usage that much memory is more than enough.

Gator said:

The only thing you may need it for is when certain programs look for it as part of their code.

Programs never explicitly ask for the pagefile in normal code, in fact normal user-mode programs aren't aware of the pagefile at all, it's handled by the OS transparently, which grants or not memory requests by programs. The only exceptions might be some poorly coded driver.

There really is no optimum size for the pagefile. The primary consideration is that the pagefile be large enough to provide a sufficiently high commit limit. This will be RAM size plus pagefile size, minus a small overhead. Even without a pagefile this will be nearly 32 GB which by all normal standards is huge. It would require a very heavy workload to come anywhere near that.

There are 2 other considerations.
1. to produce a memory dump for debugging purposes a pagefile on the system drive is required. The required size depends on the type of memory dump and some other factors.
2. Some applications will check for the presence of a pagefile and fail if it is not present. Applications can't use the pagefile themselves but use it as confirmation that the commit limit will not be reached rather than simply checking it directly. At least that is the only justification I can see.

The system managed pagefile uses the assumption that you will have a workload comparable with your RAM size. Why else would you have that much RAM? But with huge RAM sizes that is rarely the case.