VDI Paging Files – Big? Small? Or None At All?

VDI - Paging FilesFor the past few months I have been spending a lot of time looking at the performance of Large VDI environments, where the problems lay and where performance can be improved.

When designing VDI environments, a couple of things that you should consider are the .vswp file and the GuestOS paging file. In this article I am going to focus on the Paging file and hopefully in the not so distant future I will write a post about the .vswp file in a VDI environment.

What is point of the paging file (also known as the pagefile.sys)?

RAM is a limited resource. Virtual memory was introduced to help remove that limit.

Most modern operating system now use Virtual Memory. Virtual memory is a memory management technique. Applications running on a GuestOS reference memory using virtual memory addresses which are then automatically translated into RAM addresses by the hardware. These virtual memory address spaces are divided in pages or block, usually of 4KB. 

If RAM resource is exhusted, the operating system will move 4KB pages of the virtual memory onto the computers hard disk to free up the physical memory (RAM) for other processes. In Windows operating systems, these pages are stored in the pagefile.sys. 

A good way to think of this is;

Imagine a restaurant that has just open for the evening. When customers (Processes) arrive they get allocated a table (RAM) to sit and eat at. As the night goes on the restaurant get busier and free tables (RAM) begin to run out for the new customers (Processes) coming through the door. To free up spare tables (RAM) the waiter asks customers (Processes) who have finished eating if they wouldn't mind moving to the bar (Virtual Memory) where they can continue drink.

Without the paging file, if the physical memory becomes full, applications including the operating system will have to waiting until physical memory becomes available before it can be stored in RAM ready for the CPU to process. As you can imagine this causes massive performance problems.

In summary, you NEED to have a paging file.

We've always used paging files before, what makes using then in VDI any different?

Paging files are stored on the hard disk of the GuestOS. On a virtual machine the GuestOS hard disk is stored on a storage array and not a local disk (In most cases). All activity on a virtual machines hard disk issues disk Input/Output commands to the storage array that has the LUN which is hosting the VMDK onto which the GuestOS is installed. If you have one desktop IOPS caused by OS paging could be relatively insignificant, if you 6000 dekstops, its a different story.

What size should I make the paging file?

This is question that often brings back some many answers. Everyone has their own opinons on this, this is my opinion. It's completely open to discussion, so feel free to comment below.

As you can see, there is a quite a big difference between the two recommendations. You also have the option to allow Windows to manage the size of the paging.sys file (System Managed). – I'd rule this option out straight away. 

If the virtual desktops are configured with adequate RAM for the workload being performed on them, the minimum size of memory required should never increase. However, if an application with a memory leak, or something is using more memory than it should normally, the page file will increase. If the page file is set to System managed, during dynamic size adjustment operations, the disk I/O will be high and the performance of the virtual desktop may degrade. The result is significant here, as other virtual desktops on the same host and data store will be impacted.

So should I go big? or should I go small?


Yes, you've heard it before, assess the environment you are virtualizing, analyze the data to see what amount of the paging file is in use through the day. Use that data to help you decide what size paging.sys file you should use in your VDI environment.

You will more than likely find that some users use more paging file than others. Some applications use more paging.sys file than others. This is where Use Cases come into play. There is a good chance that each Use Case will have different paging.sys requirements. For example:

  • Standard Office user may use – 13% of a 1024MB paging.sys file (~133MB)
  • The Graphics team may use – 80% of a 1024MB paging.sys file (~819MB)

To find out how much of the paging.sys files is being utilized, run Perfmon on the desktop and add the following counter: 

Paging File > % Usage > _Total

Below are a could of screenshots taken from desktops which are running different applications. As you can see, there is a large different between two.

Standard Office User  Paging.sys 2


As with most things in life, it depends! I don't believe there is a one size fits all solution, unless you're lazy and decided to not bother with an assessment!

  • Analyze page file usage on the physical desktops during the assessment phase. (It is likely that paging.sys file usage will vary from use case to use case.)
  • Once implemented, monitor. You may find that you have over/under sized. Just because you have made a sizing decision doesn't mean you cannot change it easily (Recompose).

Systems evolve, software gets add/removed, requirements change – Change with it.

As always I'd love to hear your thoughts – Please use the comments section below.