Windows pagefile configuration for VDI environments has been a long standing discussion ground. I first wrote about it in 2010 (Pagefiles and VDI. Not so simple). However, because of few recent discussions I decided to review the subject and run some validation tests against well-known best practices. “The problem with best practices is that they around stay for longer than the technology they were based on.”
This validation is rather simple; one Windows 7 virtual desktop configured with pagefile, and one Windows 7 virtual desktop configured without pagefile. Besides pagefile, the virtual desktops are configured with exact same setting. In fact, both desktops originate from the same Parent VM. (Windows 7, 2GB RAM, 1GB Pagefile)
Additionally, for this test I have enabled Linked Clones. The reason for that is that with Linked Clones I am able to analyze individually the base image and the delta utilization.
Myth Number One – The Windows boot
The first myth is that during boot time a Windows virtual desktop with pagefile will produce more write IOs against virtual disks than a virtual desktop without the pagefile. The graphs below demonstrate that during boot storms read IOs are very similar. However during the boot without pagefile there was 27% less write IOs. On average number of write IOs is smaller in virtual desktops with pagefile.
Virtual Desktop with Pagefile during Boot
Virtual Desktop without Pagefile during Boot
Myth Number Two – The IDLE time
Many administrators think that the existence of pagefile automatically means that there will be more write activity, even when Windows is idle. The truth is that there is no such thing as idle time, since Windows is always running processes in the background and those processes are in most part write IO intensive. This is the reason why Windows operating systems can be as much as 80% writes during an average workload.
The graphs below demonstrate that virtual desktops during idle time with or without pagefile behave in a very similar fashion in regards to disk IO. For write IOs both virtual desktops had a maximum of 3 IOPs and an average of 0.23 IOPs.
For read IOs there was a little spike in the virtual desktop without pagefile, but that could have been a process that kicked off during the analysis period. It didn’t happen again.
What the graph below proves, is that when there is no memory pressure both virtual desktops will behave very similarly in regards to disk IO during the idle period.
Virtual Desktop Performance with pagefile during IDLE
Virtual Desktop Performance without pagefile during IDLE
Myth Number Three– The User Login
User login process generates different type of activity then boot and idle periods. Logins are as write intensive as read intensive, and that is clearly demonstrated on the average numbers when we compare read and write IOs.
For user login I ran tests multiple times. Below you will find one of the tests that represent the resultant set of all tests. The virtual desktop with pagefile enabled required less read IOs than the desktop without pagefile; on average 20% less read IOs.
On the other hand, the virtual desktop without pagefile required approximately 4% less write IOs during user login process.
The results look very similar, but the read IO difference at peak time could represent almost 16,000 IOPs in an environment with 1,000 virtual desktops. From an infrastructure perspective that could represent the requirement to add more spindles of even an additional storage array.
Most storage arrays nowadays have some type of cache to serve read IOs; some have features to serve write IOs from cache. However, write IOs cost more than read IOs due to the RAID striping mechanism that needs to occur for every write IO. The 3 IO difference at peak time would represent 3,000 IO for 1,000 virtual desktops. After RAID penalty is applied we would have 12,000 write IOs when using RAID5; or 18,000 write IOs if using RAID6.
Virtual Desktop with Pagefile during Login
Virtual Desktop without Pagefile during Login
If my workload was purely made up of Logins, than I probably would choose not to have pagefile, just to alleviate write IO pressure on storage. Please, bear in mind that this is applicable to any type of shared storage, SSD or PCIe appliance or DAS implementation.
There is a good article from Citrix’s Nicholas Rintalan (The Pagefile Done Right!) where he explains how pagefile should be used and created. Nicholas also makes mention to Mark Russinovich article (Pushing the Limits of Windows: Virtual Memory).
“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.”
I utterly agree with both authors, however Russinovich is not talking about Windows operating system running in virtual environments; and Nicholas is completely ignoring the disk IO aspect. There is more to it ($$$$) when talking about VDI.
If pagefile is not good from a disk IO perspective, what would be the impact of completely disabling pagefile? The reality is that when available memory is full Windows will start throwing Low Memory errors, and eventually generating a BSOD. I have purposely created a video demonstrating that behavior.
There are two screens side-by-side in this video. I recommend watching full screen and HD.
Most VDI deployments run on top of hypervizors and most hypervisor have some type of memory overcommit feature. VMware vSphere TPS feature allow administrators to overcommit host memory, allowing virtual desktops to have more virtual memory assigned than the total physical host memory available.
Following this idea, one could assign 4GB RAM to virtual desktops when the maximum load required is only 3GB. This way a user is able to load all the required applications without incurring in Windows swap. In this case the VMTools ballooning doesn’t seem apply, since there is no swap file.
The caveat is when all users simultaneously start using more virtual memory than existing physical host memory. In this case vSphere will compress and then host swap to disk, degrading performance for all virtual desktops on the host.
In the ideal world the administrator have carefully measure memory utilization and know the applications that users commonly use. In this case the administrator should be able to size Windows RAM properly, without having to enable pagefile.
In my work life experience I have seen organizations successfully running virtual desktop without pagefile.
For VMware View Premier and vSphere Desktop Edition there is no additional licensing costs for assigning additional virtual memory to virtual desktops.
In saying all that, if you don’t feel that you know your VDI environment, applications, and users well enough, don’t disable pagefile.