How big Should PageFile.sys be on a Server 2008 Hyper-V Server?
I received the following question:
Thanks for the article. What do you do about your host system's pagefile? I'm thinking more about size. Do you leave the default? I have a 16GB system and 12GB of that is allocated to VMs.
Do I size the host pagefile for the whole 16GB or just for the 3 or 4GB not used by the VMs? Of course, I want to reduce paging and disk I/O for the host, but if I don't need a huge pagefile, then I'd rather not.
Still researching to see if the old 1.5x RAM sizing is still applicable to x64 large-RAM Hyper-V systems.
Thanks!
Well I did some looking around and there is not a black and white answer to this one, but for the majority of your situations, I'd recommend that we let the system manage the pagefile.sys. Pagefile.sys is around for two reasons:
- Provide Virtual Memory to support the physical memory on the server. 1x-1.5x the amount of memory is the "suggested size" of the pagefile.sys, but usually that does not make "sense" on a 16GB machine, and this is "traditional guidance" that does not take Hyper-V into consideration.
- Pagefile.sys has always been available as the dump location in the event of a crash, so in this situation, sometimes you need a pagefile.sys that is at least the size of your available RAM (plus a little more). Check out the article below that discusses the details to be considered.
If the server crashes once, do you really want a dump of all of the RAM? If you do, then pagefile.sys needs to be larger than the available RAM, and the machine probably needs to be configured to allow all of the RAM to dumped. Be warned that if you do this, the memory dump could take a very long time (30 - 60 minutes?). Most likely, you don't want to run with this big of a pagefile.sys, because machines don't bluescreen that often anymore. If you do encounter repeated blue screens, you'll most likely work with a Support Professional that will help you configure the server to generate the appropriate dump anyway.
Now when we consider your situation, 4Gb is usually adequate since the other 12Gb is dedicated to the VMs. Since the VM's require real RAM, not virtual memory, there's really no reason for pagefile.sys to support the VM memory for day to day operations. Again, the only good reason I could find to have a 16Gb page file in *most* (but not all) instances is to be able to capture a memory dump in the event of a failure.
Here is the guidance on Server 2003 and WindowsXP pagefile.sys planning. While we have made some changes in Server 2008, this guidance is a very good starting place, check it out. It asks you to profile your machine with your workloads, and then take that profile information to determine the pagefile.sys size.
At this time, we do not have guidance specifically for Server 2008 and Hyper-V, but this plan should be fine in most scenarios. One thing that has changed in Server 2008 and Vista is that you can now specify a different dump file, location and size of the dump files. That's a different discussion, but the pagefile.sys guidance above should be adequate for "best practice" configurations.
As you can tell, I've hedged my bets boths ways on this because there is no one size fits all answer if you feel you need to customize the pagefile.sys configuration, but usually the pagefile.sys configuration is not an item that will impact system performance that much anymore. The pagefile.sys configuration is System Managed by default for both Server 2008 and Windows Vista. If you want to conserve space, I can see the reasoning for no more than a 4Gb pagefile.sys on a Hyper-V machine. Heck I can even see where only a 2 Gb pagefile.sys might make sense, but again, the system by default can take care of that for you.
Of my three Hyper-V machines, I've configured two of them manually so that I could move the pagefile.sys file off of the boot drive. My third machine is configured with the default configuration of System Managed. If you really want to tweak performance, putting pagefile.sys on a different drive can reduce drive contention as long as the new destination isn't hosting any other disk IO intensive applications like Virtual Machines or databases.
Until next time!
Rob
Technorati Tags: Hyper-V,Pagefile.sys,Server 2008 Hyper-V
del.icio.us Tags: Hyper-V,Pagefile.sys,Server 2008 Hyper-V