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!
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.
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:
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.
How to determine the appropriate page file size for 64-bit versions of Windows Server 2003 or Windows XP
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!