Citrix Provisioning Services - Cache to RAM (and how to monitor it)








If you want to take benefit of cheap RAM to boost your XenApp servers to extreme speed, you may use Citrix Provisioning Services (PVS) with the option to cache to RAM. The Citrix documentation tells you that this is the fastest method, but it’s not recommended as you may “loose data” if your RAM Cache gets full. I wanted to try this, and I’ve actually made it work very well with PVS Cache to RAM. Here is what you have to keep in mind to be successful:

The size of the RAM Cache

Monitor how large your PVS Cache is before next scheduled reboot. The RAM Cache has to be greater than the highest value you record, and have space for potential growth.

The size of user profiles

Most of the cache is the sum of user profiles written to the server since last reboot. If you configure PVS to use RAM Cache, let´s say with 4 GB, the sum of your peak users per box, times the largest user profiles, must not be larger than 4 GB. To keep profile size down, use Folder Redirection for Documents, Pictures, Downloads, Videos and Music. This will help you keeping the profile sizes down.

I’m using this script to collect all Citrix Profile Management profile sizes into a CSV-file:

You may download the script here

Move Page File to Persistent Disk

Yes, you still need Persistent Disks allocated to your XenApp servers. Storing page file in RAM is maybe not a good idea, as it will fill you RAM Cache immediately. The Persistent Disk should also be used for App-V cache, other app streaming type of cache and all types of log files.

Reboot at least every day

The write cache is growing as new users are logging on to the XenApp server. To keep it small, reboot at least once a day. In a 24/7 environment you may have to implement rolling server reboots to enable this. There are some nice Powershell scripts to do this at I’m using a Reboot Manager Tool I’ve developed myself for the job. I’m planning on releasing an Express version of this tool on my blog. This may also have PVS RAM monitor built into it.

Monitor the RAM Cache size

If the RAM Cache is full, your PVS device will reboot immediately. PVS has a status field that returns the RAM Cache size. The problem is that it will not report PVS Cache size when placed on disk, only when placed in RAM.

“C:Program FilesCitrixProvisioning ServicesMCLI.exe” Get deviceinfo -f devicename status

The monitor must disable the server for new logins, and alert the IT staff. I made a VBScript to do this. I tried using Powershell at first, but the PVS CMDlet seems to return strings instead of objects, thus making it hard to script. Going with MCLI.exe and VBScript was the easiest solution to me. I’m using and to disable logins and alert by SMS/email.

The script needs to run on one of the PVS servers.

 You may download the script here

Now, If you have enough RAM configured on your PVS Servers, you will have extremely fast read I/O, and fast write I/O, as I/O writes is stored in RAM on the device. If the Persistent Disk is on Shared Storage, you will also be able to live migrate the PVS devices in a virtual environment. To speed things up, schedule a startup of commonly used apps after every reboot to read these apps into RAM. This will speed up app startup for the first users logging into each box. We are using scheduled Citrix EdgeSight For LoadTesting scripts at server startup to load the most commonly used applications at every reboot.

6 thoughts on “Citrix Provisioning Services - Cache to RAM (and how to monitor it)

  1. Very interesting article, I’ve been using cache to RAM for some customers since a year or so and performance has been great.

    I did enlarge the cache to 16GB for the customers that use RAM as a cache, just to make sure the server to run out of cache… don’t want to see them rebooting.
    Our general cache usage during the day with 20 users per virtual XenApp server and 80 user per host was 4GB per virtual server. We never saw a much higher number. We also redirected everything that you normally do and used RES Workspace Manager to keep the profile clean and small..

    I wrote a blog about our experiences a while back :

    Gonna take a look at your scripts and see if I can use them.

  2. Very nice. We have had success with NO PAGE file in the servers so that removes the need for persistent disk if app streaming is not used.

  3. I agree that the size of profiles is key to ram cache usage (or write cache on disk for that matter) but one must also account for the spooler and large print jobs in environments with lots of printing as in ours, print jobs can be several hundreds of MBs 🙂 Is the size of the RAM cache , as configured on the vdisk properties, an upper limit or will that amount immediately subtracted from the available ram on boot similar to AWE/LP in windows? Also, might putting the pagefile in RAM cache not make sense as it’s likely to have the most writes to it if on persistent storage? That way even hard page faults are lightening fast.

  4. Nice article. Pity PVS doesn’t appear to expose any target side per counters to real time monitor your RAM cache though with SCOM etc! Also, Bryan, how are you running with no page file? Windows 2008 r2 will create one on the fly even if you don’t.

  5. Great Post!!! only one change in the Citrix Profile Size Script in this line:

    if err.number = 0 then f.WriteLine flexfold.path & “,” & FormatNumber((flexfold.Size/1048576),2, , ,vbFalse) & “,MB”

    its to disable GroupDigits in the function FormatNumber.


Leave a Reply

Your email address will not be published. Required fields are marked *