Here are my notes on paging file recommendations for SharePoint (2007, 2010, and 2013). This is something I always like to check when a new farm is built or I'm looking at a poorly performing farm for the first time. Often they're set too low.
Also I tend to recommend moving the page file off of the system partition and onto a spare drive for multiple reasons. SharePoint health rules often complain about lack of free space on the C: drive. Moving the page file is one way to get around that problem and may give increased performance simultaneously.
One TechNet article says SharePoint servers needs to one paging file and that the paging file should be. . .
"equal to or greater than the total amount of available physical memory. . . We recommend that you either allow the system to manage the page file size or to set it at 150% of the size of the physical RAM."
A reliable KB article
that talks about Windows servers in general (but not SharePoint servers in specific) also harmonizes with this saying. . .
"the traditional model of the page file should be at least the size of physical ram plus 1 MB, or 1.5 times the default physical RAM. . . 1.5 times the physical memory."
Another TechNet article predicated upon a SharePoint 2010 Health Analyzer rule says. . .
A Windows best practice is to set the paging file size to equal to or greater than the total amount of available physical memory. Garbage collection is typically more effective at automatic recovery of heap memory when managed heap size approximates paging file size. When paging file size is smaller than RAM size, new allocations of managed memory are granted, which leads to more garbage collection and higher CPU usage. . . We recommend that you either allow the system to manage the page file size or to set it at 150% of the size of the physical RAM.
If you have more than one local drive on the server, it may be a good idea—sometimes a VERY good idea—to move your page file off of the C drive and onto the other drive. So what are the cons and pros for doing so? The arguments summarized below are from an old-but-good kb article.
To enhance performance, move the paging file to a different partition. When the paging file is on the boot partition, Windows must perform disk reading and writing requests on both the system folder and the paging file. When the paging file is moved to a different partition, there is less competition between reading and writing requests.
When you place a paging file on its own partition, the paging file does not become fragmented, and this counts as another definite advantage. If a paging file resides on a partition that contains other data, it may experience fragmentation as it expands to satisfy the extra virtual memory that is required. An unfragmented paging file leads to faster virtual memory access and greater likelihood of a dump-file capture that is free of significant errors.
However, if you completely remove the paging file from the boot partition, Windows cannot create a dump file (Memory.dmp) in which to write debugging information in the event that a kernel mode STOP error message occurs. This can lead to extended downtime if a debug procedure is necessary to troubleshoot the STOP error message. [But really now. When was the last time you had to make a kernel dump of a server? Seven years ago? If you really need to make a kernel dump, you can switch the pagefile back to the C: drive temporarily, make your kernel dump, and switch it back to the other drive after making the dump. You might have to clear up some space on C: to do it. To make the dump, the size of the page file needs to equal the size or physical RAM]
"[One possible solution to consider] is to create one paging file that is, by default, stored on the boot partition, and then create one paging file on another, less frequently accessed partition. Additionally, it is optimal to create the second paging file so that it exists on its own partition, with no data or operating-system-specific files. By design, Windows uses the paging file on the less frequently accessed partition over the paging file on the more heavily accessed boot partition. An internal algorithm is used to determine which paging file to use for virtual memory management."
Make your way to System Properties (varies for different operating systems) and select the Settings button under Performance
Select the Advanced tab and click the Change button under Virtual Memory
If the recommended size is 150% of the physical RAM you might be able to get away with setting the bullet beside System Managed File. But it may be better to set it exactly to 150% of RAM by placing the bullet beside CUSTOM SIZE and setting both the initial and maximum sizes to 150%. Or you could try setting the initial size to 100% of the RAM on the server and set Maximum size to 150% of RAM.
Rule Name: The paging file size should exceed the amount of physical RAM in the system
Summary: The paging file size on some servers in the SharePoint farm is smaller than the total physical memory that is available on the servers.
Rule Name: Drives are running out of free space
Summary: Disk drives on one or more of the servers in the farm are running out of disk space.
Rule Name: Drives used for SQL databases are running out of free space.
Summary: The databases have one or more files that exceed the available free disk drive space. If this happens, operations will fail. A disk drive should have enough free space to allow the largest database file to automatically grow to twice its size.