Advertisements

Windows VM Page File Policies

Every once in a while people will ask why their VM is not performing well.

Well there are many areas where you can look, at the host level, for example by adding more memory to the host or by looking at the guest level.  Today, we are going to focus at the guest level and focus in particular on the usage of Page Files in Windows guests.

Page Files for example, are a simple matter.  However, you have them at the host level and at the guest level and you don’t want your virtual machines to be writing to the page files all the time as swapping out memory to disk will have a HUGE performance impact.

So what is the first thing you can do to mitigate performance problems? Well you can select a reasonable memory size on your VM so that your memory is not constantly swapped.  As a tip normally a good starting point is for windows Vista/2003/2008 is to select 1GB, Windows XP desktops usually do fine around 800MB and resize up or down depending on your needs. Check the Task Manager and verify how much of the page file is being utilised. It is OK that it is being used, memory that is not in constant use, does not have to be in physical memory.  Just confirm that your page file usage is not consistantly over the internal memory size as that would indicate memory starvation.

Which brings us to size. I personally prefer to set a Page File size statically to 2x the internal memory.  However MS recommended 1.5 times physical memory so you could start at 1.5 times and that should be OK. There are some limits here, for example On a 32bit machine the page file can never be bigger than 4GB.  One thing you do NOT want is a dynamically resizing page file, that is the system managed page file and which just happens to be the default.  At least it is in Windows XP. It grows and shrinks depending on usage. Great for fragmenting your drives and data on it.

If you get warnings that your page file is too small and that it will be resized, your VM will suffer a huge performance penalty, not only that, your page file will defragment heavily (and all files around it too)

This is the one of the main reason why a windows page file should be placed on a separate virtual disk. So in a Windows XP VM, do add a 2GB extra disk which is used for storing the page file on only. The disadvantage of not having a page file on your system disk, is that you can no longer make crash dumps. The advantages are:

  • As your page file is on its own disk, it will no longer fragment
  • The files on your other disks will not fragment because of your page file growing/shrinking
  • Backups do not have to include the page file disk, it can be regenerated on reboot, you can include a disk with a zeroed out page file for this.
  • As the virtual controller now has the page file on another “disk”, it can use another channel. Yes this is in software and speed improvements will be negligable, but its still positive. You can even use another virtual controller by changing the reference in your vmx file from scsi0:2.filename to scsi1:2.filename so you can saturate even more buffers. sarcasm true, but you could do it 😉
  • You can now put your page file on another faster spindle if your host has multiple disk systems / spindles

If you still want to be able to make crash dumps then you can also add a small -fixed size- page file on the boot disk of your VM.

External references:

http://blogs.technet.com/askperf/archive/2007/12/14/what-is-the-page-file-for-anyway.aspx

Advertisements

5 comments

Skip to comment form

    • PiroNet on April 27, 2009 at 3:37 pm

    Perhaps one of the most commonly asked questions related to virtual memory is how big should I make the paging file? Paging is something you don’t want to do, especially in VM’s because it kills your performance. 1.x or 2.x, even Microsoft has published misleading recommendations.

    So how can I find out the right amount?
    To optimally size your paging file you should start all the applications you run at the same time, load typical data sets, and then note the commit charge peak (or look at this value after a period of time where you know maximum load was attained). Set the paging file minimum to be that value minus the amount of RAM in your system (if the value is negative, pick a minimum size to permit the kind of crash dump you are configured for). If you want to have some breathing room for potentially large commit demands, set the maximum to double that number.

    http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx

    • Tom on April 27, 2009 at 4:45 pm

    Why did you write about XP when many people using VMware are running Win2k8 and Win2k3??

    If the separate pagefile drive that you recommend is on the same disk/LUN as the VM, what difference does this make other than possibly being able to exclude it from backups??

    Thank you, Tom

  1. firstly I was writen by Wil 😉 but mainly the focus was XP as that is the OS that as a VDI guy I tend to utilise on a day to day basis, the rules outlined in the blog are just as pertanent to Win2K3 and Win2K8.

    As to the seperate pagefile, it the disk is in the same locatition as the rest of the drives then you do gain the lack of fragmentation. and the ability not to back up the disk, thereby reducing your backup by about 1.5 to 2GB per machine, that said, the XP machines in my deployments tend not to be in the backup cycle anyway, only the Master Images and Snap of linked clones of the Golden Template image if a traditional thick deployment.

    Your savings will be on Server based OS’s as you can have the Page file on a fast RAID10 LUN and also not part of the backup cycle

    • Jason H on April 29, 2009 at 10:50 pm

    Let’s look at this objectively (Windows). If a system is a likely candidate for virtualization and you have done your homework none of this is going to be an issue for you. Part of your homework is sizing things correctly. As for backups omit pagefile.sys from being backed up. Next if you are running VMs in an Enterprise Environment then you are using shared storage and most likely a SAN with FC connectivity. Here is my point with shared storage. The current version/build of VMware ESX does not support multipath I/O (MPIO) so no matter what LUN or partition you put a pagefile on is going make a difference because all I/O requests are handle by a single HBA at any given time. Your point of file fragmentation could be correct if your pagefile is being used a lot. If it is being used a lot this would indicate me to that instead of growing the pagefile you would need to make it smaller and provide additional physical memory to the virtual machine. Try it without a pagefile. As an endnote when Windows starts up it consumes a large portion of physical memory even if it isn’t being used and is very bad about giving it back for later use. The ESX kernel can be fine tuned to recover the memory that isn’t being used by the OS. This is where I might put some additional focus if you are seeing some memory contention.

    Remember the original purpose of virtualization is to better utilize the ridiculously underutilized hardware more efficiently.

    • T-Rex on June 19, 2009 at 1:41 am

    I would like to donate copies of our Stratusphere VDI Diagnostics Virtual Appliance to anyone interested in doing some benchmarking on the points raised herein, or other advanced memory, cpu, IO, or disk transaction activity. No strings attached. I just think the community would benefit from some detailed analysis and perhaps “gray-papers” on this subject, OS managed pagefiles, lun performance hits/gains, open postings of findings, caveats, challenges, memory tuning, IO observations, cpu vs memory strategy correlations, io vs memory strategy correlations, etc. We collect this data, eager to see the groups thoughts on results…BTW, not sure what a Gray Paper is, it just sounded cool. 🙂

Comments have been disabled.

%d bloggers like this: