Exchange Server 2010 and page file location
I have a question regarding page file location. I have read through the technet articles on what is required for page file size (physical memory +10mb) but I have a question on what is recommended for page file location. My storage vendor, I am virtualizing Vmware esx 4.1 with Compellent storage. The storage vendor has recommended putting the page file on it's own drive and not on the OS C:\ drive. I had read somewhere on technet where Microsoft recommends it being on the OS drive. Any advice, suggestions or comments on this subject would be very helpful. Thanks in advance.
March 31st, 2011 10:33am

Hi Travis, I've noticed that MS indeed recommends to keep the paging-file on the system disk; however - if I'm not mistaking - they recommend that so that a memory dump could be created in case of a STOP error. Where "needed" - I've placed the page file on a seperate disk (of its own) to increase performance even though Exchange 2010 is optimized to minimize the use of the paging file (actually it's built to use the memory as optimal as possible). If I'm correct, Exchange uses the paging file mainly for content searching (at least for Exchange 2007 that is the case, I don't really know for Exchange 2010 - never saw an article on that). Note that there are other reasons for the page file to exist too! On the other hand, moving the paging file is only usefull if it really offers an advantage (monitoring is key!). I've come across scenario's where the paging file was moved from partition (on the same disk) which obviously makes no sence at all (or almoste no sence) :) Grts, Michael
Free Windows Admin Tool Kit Click here and download it now
March 31st, 2011 2:46pm

My main concern is this. It's a virtual environment using virtual disks. I can expand virtual disks other than the boot drive on the fly. If I would happen to add more memory to the virtual machine in the future, i would need to increase the page file size. I do not want to get into the situation of not having enough space on the boot drive due to the fact of the page file needing to be expanded. Thoughts?
March 31st, 2011 3:04pm

Well, it depends on what function of the Page File we are talking about. It can logically be split into servicing two different functions of a hard working busy (Exchange) server. 1) Virtual RAM when the server runs out of physical memory. 2) Place to store the dump file after a BSOD (Blue Screen Of Death) Viewing it from point 1) the Page File should be located on any high performing physical disk other than the disk holding the C:\ drive as a way to maximize performance. But not a RAID since it can negatively impact the write speed which i key. But this isn't good for point 2) since it is needed to be on the systemdrive C:\. Well, actually this was true in Windows Server OS before Server 2008. Since we are talking about Exchange 2010 we know you are using a newer server version (2008 or 2008 R2) and then you have the option to tweak the location of the dump file: "Windows Server 2008 does not require the page file to exist on the partition that the operating system is installed on. To put the page file on another partition, you must create a new registry entry named DedicatedDumpFile." So go for a separate physical disk, without RAID and tweak the DumpFile location.Jesper Bernle | Blog: http://xchangeserver.wordpress.com
Free Windows Admin Tool Kit Click here and download it now
March 31st, 2011 3:36pm

How will you, or will you, backup the OS partition of the Exchange server? When you virtualize, you can certainly have more than one virtual hard disk, and those disks will load early in the boot cycle (to the guest they appear local). The SAN array can be sized to handle the load. The layout issue here really comes down to backup strategy. If you are going to use snapshots at the hypervisor or on the windows LUNs to backup your system state, then it makes sense to put the page file on a different LUN (with a different or no backup plan) in order to reduce the size of those snapshots. This is likely the heart of your SAN vendor's guidance. John
April 2nd, 2011 1:44pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics