Tag Archives: cache

XenServer PVS Accelerator Sizing – Part 2

As you might have read, I recently ran a few XenServer PVS Accelerator tests to determine a starting point for the cache size.  This initial investigation looked at Windows 10 and Windows 2012R2 for boot and logon operations.

Looking back, I determined that I want to include three additional items

  1. Impact of a larger cache size – Increase from 2GB to 4GB RAM cache
  2. Impact of applications
  3. Impact of Windows 2016

Before I get into the results, let me explain the graphs.

  • The blue, green and orange line denotes boot, logon and steady state operations. The first time those colors appear depicts the first VM; the second time the colors appear depicts the second VM. These colors are linked to the axis on the right showing percent of cache used.
  • The solid red area graph depicts the amount of network traffic sent from the Provisioning Services server to the host.  The line should initially be large and then diminish as the cache is used. It is linked to the left axis with bytes per second.

With that understanding out of the way, let’s look at the results.

Windows 2012R2

Windows 10

Windows 2016


First, I find it interesting that Windows Server 2016 sits between Windows 2012R2 and Windows 10 in terms of cache consumption after boot, logon and steady state operations complete. This makes sense as Windows 10 and Windows Server 2016 are considered to be similar operating systems, requiring more cache than Windows 2012R2.  But it also shows that Windows Server 2016 is more optimized, with fewer extraneous apps/services as shown in the Windows 2016 Optimization guide.

Second, even though the size of the PVS Accelerator cache was doubled 4GB from 2GB from previous tests, the overall usage remained the similar.

Third, the biggest cache utilization during logon and the least during steady state. Usage matched expectations based on read/write IO ratios for boot (80% read / 20% write), logon (50% read / 50% write) and steady state (10% read / 90% write). The more unique read IO activity, the more cache utilized.

Based on this round of tests, I’m sticking with my previous PVS Accelerator cache size recommendation and adding Windows Server 2016:

  • Windows 10: 2.5GB per image per host
  • Windows 2012R2: 2GB per image per host
  • Windows 2016: 2.5GB per image per host

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.6 VDI Handbook
XenApp Best Practices
XenApp Video


XenServer PVS Accelerator Cache Sizing

How large should we make our PVS Accelerator cache? Too large and we waste resources. Too small and we lose the performance.

Let’s take a step back and recall our best practice for sizing the RAM on Provisioning Services.  We would typically say allocate 2GB of RAM for each vDisk image the server provides.  This simple recommendation gives the PVS server enough RAM to cache portions of the image in Windows system cache, which reduces local read IO. So for a PVS server delivering

  • 1 image:  we would allocate 2GB of RAM (plus 4GB more for the PVS server itself)
  • 2 images:  we would allocate 4GB of RAM (plus 4GB more for the PVS server itself)
  • 4 images:  we would allocate 8GB of RAM (plus 4GB more for the PVS server itself)


Let’s now focus on the XenServer portion of PVS Accelerator. If we use RAM as our PVS Accelerator cache, how many GB should we allocate?

I decided to test this out.  I first set my PVS Accelerator cache to use 2GB of RAM.

Once configured, I booted and logged into a single VM. I then started a second VM on the same XenServer host.

Let’s first look at the Windows Server 2012R2 results:

When the first VM starts, the cache is empty so while the VM boots and a user logs in, the cache gets populated. When the second VM starts, it doesn’t increase the size of the cache because everything it needs to boot and log on a user has already been cached.

The expectation is that Windows 10 should show a similar behavior.

The difference between Windows 10 and Windows 2012R2 in regards to PVS Accelerator is the amount of cache consumed during bootup and logon.  Windows 10 uses significantly more cache than Windows 2012R2.

Windows 2012R2 uses 40% while Windows 10 using 80%.  So based on this, what should we allocate per XenServer host?  2GB? 1.5? 2.5?

First, remember that the boot process is weighted heavily on reads. The read/write ratio is close to the following:

  • Boot: 80% Reads : 20% Writes
  • Logon: 50% Reads : 50% Writes
  • Steady State: 10% Reads : 90% Writes

Second, these graphs only show boot and logon.  Users haven’t loaded any applications, which will initiate read operations, thus increasing the cache utilization.

Third, we have a limited supply of RAM.  Our goal isn’t to eliminate all reads, it is to significantly reduce them.

Based on that, I’d start with the following and MONITOR:

  • Windows 10: 2.5GB per image per host
  • Windows 2012R2: 2GB per image per host

Remember, the key is “per image per host”.

The PVS Accelerator cache is host specific. If my XenServer host is supporting VMs using 4 different images, I need my PVS Accelerator cache to be large enough to cache enough of the read IO to be beneficial across all 4 images.

If our environment is large enough, we will want to look at segmenting our XenServer hosts into groups of servers that host a few images. That way we can reduce RAM allocation for PVS Accelerator.

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.6 VDI Handbook
XenApp Best Practices
XenApp Videos

Does Cache Trump IOPS

With desktop virtualization, we hear more and more about how important IOPS are to being able to support the virtual desktop. I’ve had a few blogs about it and plan to have a few more. What I wanted to talk about was an interesting discussion I recently had with 3 Senior Architects within Citrix Consulting (Doug Demskis, Dan Allen and Nick Rintalan).  There are 3 smart guys who I talk to fairly regularly and the discussions get quite interesting.

This particular discussion was no different.  We were talking about the importance of IOPS, RAID configs, spindle speeds with regards to an enterprise’s SAN infrastructure. (Deciding if you are going to use a SAN for your virtual desktops is a completely different discussion that I’ve had before and Brian Madden had more recently). But for the sake of this article, let’s say you’ve decided “Yes, I will use my SAN.” If your organization already has an enterprise SAN solution, chances are that the solution has controllers with plenty of cache. Does this make the IOPS discussion a moot point? Continue reading Does Cache Trump IOPS

Not Spending Your Cache Wisely

It almost sounds like I’m talking about personal finances. You better plan your cache appropriately or you will run out. I’m not talking about money; I’m talking about system memory (although if you plan poorly we will quickly be talking about money).

It comes down to this… system cache is a powerful feature allowing a server to service requests extremely fast because instead of accessing disks, blocks of data are retrieved from RAM. Provisioning services relies on fast access to the blocks within the disk image (vDisk) to stream to the target devices. The faster the requests are serviced, the faster the target will receive. Allocating the largest possible size for the system cache should allow Provisioning services to store more of the vDisk into RAM as opposed to going to the physical disk.  Continue reading Not Spending Your Cache Wisely