Sizing the Page File for Hyper-V Host Server

Like many things in the Hyper-V world understanding and attributing resources is extremely important. The page file is an important aspect of debugging servers and can in some instances allow servers to handle situations which temporarily exceed the physical memory of the server.

Without rehashing the importance of the page file, in this post I will try to give reference and personal opinion on page file size and the thinking behind the conclusions.

It is important to note that no significant testing or guidance exists to my knowledge at the time of writing about sizing page files which is based on  scientific method. This article is an opinion piece and will be clearly stated as such. Often we as experts in the field are asked for our opinion without the facts to back it up. Although we are often correct, specific circumstance may not be considered and special care should be given to evaluate your circumstances prior to following guidance contained herein.

Background

Patrick Lownds wrote an informative piece here: http://www.mvug.co.uk/blogs/mvugblog/archive/2008/11/27/page-file-sizing-for-the-root-parent-partition.aspx

MSDN described the three types of Kernel Mode Dump files here:

http://msdn.microsoft.com/en-us/library/ff560246(v=VS.85).aspx

Considerations

Production: Hyper-V Server in my opinion are best deployed in clusters which have a certain degree of fault-tolerance and redundancy. In such a circumstance one has to consider how much time you will spend troubleshooting scenarios with specific error conditions before you simply rebuild the box. In most production environments, the ability to rebuild a Hyper-V Host is automated and can be accomplished in less that 15 minutes. So why is this important?

If you have pre-determined that troubleshooting a server is not worth the time it takes and it is simpler to rebuild a fresh server Crash dumps and the resulting disk space allocations are not required. For that reason the use of a page file is of minimal value. In a production environment therefore, a Mini Dump is all that may be required and the page file can be sized at anything over 64 KB.

Testing and Debugging: In a testing environment or if you find yourself in a repeatable circumstance where more debugging might be required a Kernel mode dump will be most helpful.

This kind of dump file is significantly smaller than the Complete Memory Dump. Typically, the dump file will be around one-third the size of the physical memory on the system. Of course, this quantity will vary considerably, depending on your circumstances.

This dump file will not include unallocated memory, or any memory allocated to user-mode applications. It only includes memory allocated to the Windows kernel and hardware abstraction level (HAL), as well as memory allocated to kernel-mode drivers and other kernel-mode programs.

For most purposes, this crash dump is the most useful. It is significantly smaller than the Complete Memory Dump, but it only omits those portions of memory that are unlikely to have been involved in the crash.

The single server: Well, to be honest I am not a huge fan of this scenario. In my mind it adds complexity and does not add a lot of value. With the ability to install to VHD one should question what value virtualization has in a single box scenario. Multiple workloads would be better hosted in a two server environment with an iSCSI target. Having said that its out there and I have installed them and run them myself. In a single server production scenario where you have disk space I suggest the size remain RAM +1 MB. You just want to afford yourself every opportunity to recover from a crash.

Good luck and I hope this article has been helpful in exposing different considerations when allocating resources to the page file.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>