Hyper-V Page File Considerations
How big should your page file be on a Windows Server system that is being used as a Hyper-V host? Should you configure the page file size manually or let it be system-managed? Are there different page file recommendations for Hyper-V hosts running Windows Server 2012 R2 versus those running Windows Server 2008 R2?
These should be simple questions to answer, shouldn't they? Unfortunately there don't seem to be any hard and fast recommendations from Microsoft on these matters, so let's explore this further.
General recommendations for page file
Microsoft's "official" recommendations concerning page file for Windows Server can be found summarized in KB 2860880. Microsoft points out that there are two main reasons for having page file on Windows Server systems:
- To extend the system commit memory so data can be paged to disk when the system doesn't have enough physical RAM.
- To allow a system crash dump to be saved for troubleshooting purposes when Windows experiences a crash.
Note that the second requirement can be sidestepped on Windows Server 2008 R2 and later by configuring the DedicatedDumpFile registry value on the server. What this does is to create a special page file that is used solely for the purpose of storing a system crash dump file should one be created. There's a good explanation of how this works on the NTdebugging blog on MSDN. This functionality was first introduced by a hotfix for Windows Server 2008 R2 which was described here.
Of course, page files also serve a third purpose on computers running Microsoft Windows, namely to back memory pages that are infrequently accessed by Windows so these pages can be removed from physical RAM to make room for more frequently accessed pages. This harkens back to the early days of Microsoft Windows when RAM was expensive and memory-swapping like this was needed in order to allow more applications to run on the computer. But since there's a performance hit when paged files need to be retrieved from disk, so if you want your applications to be responsive and perform as well as possible, the best approach is simply to put more RAM in your server because as Microsoft says in their KB article:
"If you have enough RAM installed in your computer, you may not require a page file at all, unless one is required by a specific application."
That last bit refers to special types of servers where a page file is still required. Examples of such servers are domain controllers and Microsoft Exchange servers, and you can read the KB article for more exceptions like these.
But note what Microsoft just said there: If you have enough RAM in your server, you might not need a page file at all. Does this mean you can simply disable the page file on your quad-processor server with 512 GB of RAM installed?
Wait a moment. Let's get back to focusing on servers that are being used solely as Hyper-V hosts with no other roles installed. The same KB article has the following recommendation concerning such servers:
For Windows Server 2012 Hyper-V and Windows Server 2012 R2 Hyper-V, the page file of the management OS (commonly called the host OS) should be left at the default of setting of "System Managed." This is per the Hyper-V product group.
That seems to answer the question about page file size for Hyper-V hosts running Windows Server 2012 and later, but what about for hosts running Windows Server 2008 R2?
Page file considerations for Windows Server 2008 R2 hosts
The key thing to understand is that the Microsoft hypervisor doesn't actually make use of the page file on Windows Server systems. So if you're Hyper-V host is running a Server Core installation and has no other server roles installed except the Hyper-V role, then you might think there's really no need for a page file at all, right?
Well that's almost true. Although you don't have any server roles other than Hyper-V installed in the parent partition, you may have some additional services running there. Examples of such services might include backup agents, system monitoring agents, and other services either from Microsoft, third-party ISVs, or home-grown code. Not only may some of these services function better with a page file around, there is also another important reason you may want to configure a page file when you have such services running: memory leaks. If one of your services is flakey and is leaking memory as it runs, it's possible that available RAM will gradually be used up until the performance and reliability of the virtual machines running on your host are negatively affected. Poorly designed drivers for networking and storage devices can also leak memory and can eventually have a similar negative affect on your host's ability to run its virtualized workloads.
Configuring the page file with its default value of "System Managed" can resolve this problem by allowing the page file to grow to accommodate such memory leaks, but it doesn't address the root of the problem. And in some scenarios using the "System Managed" page file setting can have other negative consequences. For example, let's say you're booting your Hyper-V host from a 100 GB LUN on a SAN. You chose this size for the host's boot volume for two reasons: Windows Server only needs a few dozen GB free disk space according to the system requirements for the platform, and SAN storage is expensive so you want to use as little of it as possible for your host's boot volume. But then what if Windows decides that the "System Managed" setting necessitates a page file larger than the available free space on the volume? Windows will then be constrained to use a page file size that is not optimal according to its own calculation. And as the effect of the memory leak worsens, Windows may further "manage" the size of its "System Managed" in a way that makes page file performance even less optional over time, causing performance degradation for your host and its workloads. All of this can be compounded if the problem driver or service uses memory mapped files.
The solution in this case appears to be twofold:
- Manually configure the maximum size for your page file so that together with your Windows installation it won't exceed free disk space on your boot volume (leave yourself a margin of room as well).
- Monitor paged pool memory, non-paged pool memory, and other memory performance counters to detect memory leaks as they occur. If a leak is found, contact the vendor of the driver or service and ask that they fix it immediately.
What are good values for the initial and maximum page file sizes for a Windows Server 2008 R2 Hyper-V host? I've heard different recommendations from my contacts in the field, but they all boil down to configuring about 8 GB for initial page file size and 12 GB for maximum. These recommendations are for people who are running Windows Server 2008 R2 Hyper-V hosts that have up to about 128 GB of physical RAM installed in their systems. I know much fewer people who have hosts with 256 or 512 GB RAM installed and their recommendations are more difficult to summarize so I won't go into that here but may follow up with an additional article in the future if I learn anything that might be useful for readers who have systems like these deployed in their environment.
Two caveats however concerning the above:
- Don't forget that a maximum page file size of 12 GB actually means 12 x 1024 x = 12288 MB and not 12 x 1000 = 12000 MB.
- If desired you can set both the initial and maximum page file sizes to the same value (e.g. 12288 MB).
Remember that "System Managed" page files are a lot smaller in Windows Server 2012 and later. For more info see this post on the Ask The Core Team blog. I mention this here just to clarify that what I was talking about in the previous section (i.e. manually configuring custom page file sizes) applies only to Hyper-V hosts running Windows Server 2008 R2. For hosts running Windows Server 2012 and later you should follow Microsoft's recommendation of leaving your host's page file set to "System Managed".
If you want to monitor for memory leaks on your Hyper-V host, you can use the Hyper-V template for the Performance Analysis of Logs (PAL) tool available from CodePlex. Use this for a couple of weeks to monitor for memory leaks and if none are discovered then turn monitoring off. If a patch is released for a service or an updated version of a driver is available however, turn monitoring on again once the patch has been applied or driver updated and watch for a few more weeks to make sure a new leak doesn't appear.
Finally, turning on Dynamic Memory on your Hyper-V host requires some consideration with regard to configuring the page file on a Windows Server 2008 R2 Hyper-V host. You can read more about this issue in the following post on Mark Ghazai's blog. However you shouldn't have to worry about such tweaks on hosts running Windows Server 2012 and later since the root reserve and page file logic has been much improved on those platforms.