Understanding Write Cache in Provisioning Services Server

This article provides information about write cache usage in a Citrix Provisioning, formerly Provisioning Services (PVS), Server.

Write Cache in Provisioning Services Server

In PVS, the term “write cache” is used to describe all the cache modes. The write cache includes data written by the target device. If data is written to the PVS server vDisk in a caching mode, the data is not written back to the base vDisk. Instead, it is written to a write cache file in one of the following locations:

When the vDisk mode is private/maintenance mode, all data is written back to the vDisk file on the PVS Server. When the target device is booted in standard mode or shared mode, the write cache information is checked to determine the cache location. When a target device boots to a vDisk in standard mode/shared mode, regardless of the cache type, the data written to the Write Cache is deleted on boot so that when a target is rebooted or starts up it has a clean cache and contains nothing from the previous sessions.

If the PVS target is using Cache on Device RAM with overflow on hard disk or Cache on device hard disk, the PVS target software either does not find an appropriate hard disk partition or it is not formatted using NTFS. As a result, it will fail over to Cache on the server. The PVS target software will, by default, redirect the system page file to the same disk as the write cache so that the pagefile.sys is allocating space on the cache drive unless it is manually set up to be redirected on a separate volume.

For RAM cache without a local disk, you should consider setting the system page file to zero because all writes, including system page file writes, will go to the RAM cache unless redirected manually. PVS does not redirect the page file in the case of RAM cache.



Cache on device Hard Disk

Requirements

  • Local HD in every device using the vDisk.
  • The local HD must contain a basic volume pre-formatted with a Windows NTFS file system with at least 512MB of free space.

The cache on local HD is stored in a file called .vdiskcache on a secondary local hard drive. It gets created as an invisible file in the root folder of the secondary local HD. The cache file size grows, as needed, but never gets larger than the original vDisk, and frequently not larger than the free space on the original vDisk. It is slower than RAM cache or RAM Cache with overflow to local hard disk, but faster than server cache and works in an HA environment. Citrix recommends that you do not use this cache type because of incompatibilities with Microsoft Windows ASLR which could cause intermittent crashes and stability issues. This cache is being replaced by RAM Cache with overflow to the hard drive.

Cache in device RAM

Requirement

  • An appropriate amount of physical memory on the machine.

The cache is stored in client RAM. The maximum size of the cache is fixed by a setting in the vDisk properties screen. RAM cache is faster than other cache types and works in an HA environment. The RAM is allocated at boot and never changes. The RAM allocated can’t be used by the OS. If the workload has exhausted the RAM cache size, the system may become unusable and even crash. It is important to pre-calculate workload requirements and set the appropriate RAM size. Cache in device RAM does not require a local hard drive.

Cache on device RAM with overflow on Hard Disk

Requirement

  • Provisioning Service 7.1 hotfix 2 or later.
  • Local HD in every target device using the vDisk.
  • The local HD must contain Basic Volume pre-formatted with a Windows NTFS file system with at least 512 MB of free space. By default, Citrix sets this to 6 GB but recommends 10 GB or larger depending on workload.
  • The default RAM is 64 MB RAM, Citrix recommends at least 256 MB of RAM for a Desktop OS and 1 GB for Server OS if RAM cache is being used.
  • If you decide not to use RAM cache you may set it to 0 and only the local hard disk will be used to cache.

Cache on device RAM with overflow on hard disk represents the newest of the write cache types. Citrix recommends using this cache type for PVS, it combines the best of RAM with the stability of hard disk cache. The cache uses non-paged pool memory for the best performance. When RAM utilization has reached its threshold, the oldest of the RAM cache data will be written to the local hard drive. The local hard disk cache uses a file it creates called vdiskdif.vhdx.

Things to note about this cache type:

  • This write cache type is only available for Windows 7/2008 R2 and later.
  • This cache type addresses interoperability issues with Microsoft Windows ASLR.



Cache on Server

Requirements

  • Enough space allocated to where the server cache will be stored.
Server cache is stored in a file on the server, or on a share, SAN, or other location. The file size grows, as needed, but never gets larger than the original vDisk, and frequently not larger than the free space on the original vDisk. It is slower than RAM cache because all reads/writes have to go to the server and be read from a file. The cache gets deleted when the device reboots, that is, on every boot, the device reverts to the base image. Changes remain only during a single boot session. Server cache works in an HA environment if all server cache locations to resolve to the same physical storage location. This cache type is not recommended for a production environment.

Additional Resources

Selecting the Write Cache Destination for Standard vDisk Images

Turbo Charging your IOPS with the new PVS Cache in RAM with Disk Overflow Feature

Related:

db cache advice

We are on 9.2.0.5 with all bells and whistles, on a Solaris Sunfire box with 8G ram and 8 cpus. The storage is on a very fast Hitachi SAN. We have memory to burn but will likely get more cpus soon, because we have a bunch of big partitioned tables with 16 parallel query servers maxxed out on them a lot of the time. My max_sga_size is about 1.3G right now, so we are not taxing this box at all. We share it with nothing else. I believe there is such a thing as making the sga and its components too big, but would like to know your opinion on what I am seeing. Our workarea size policy is auto and the pga aggregate target is about 490m.

I found this thread most interesting, and read the link you placed above showing how to interpret the results of the query :

select

SIZE_FOR_ESTIMATE, BUFFERS_FOR_ESTIMATE, SIZE_FACTOR, BUFFERS_FOR_ESTIMATE, ESTD_PHYSICAL_READ_FACTOR,

ESTD_PHYSICAL_READS

from v$db_cache_advice;

and here is our result:

sz4_est siz_fctr bufs4_est est_p_rd_fctr est_p_rds

——- ———- ———– ————- ————

16 .0833 1,008 1.8692 233,022,616

32 .1667 2,016 1.4862 185,281,178

48 .25 3,024 1.3169 164,176,887

64 .3333 4,032 1.1989 149,464,620

80 .4167 5,040 1.1345 141,437,397

96 .5 6,048 1.1028 137,478,610

112 .5833 7,056 1.0782 134,408,245

128 .6667 8,064 1.0496 130,850,940

144 .75 9,072 1.0303 128,439,539

160 .8333 10,080 1.0189 127,017,055

176 .9167 11,088 1.0092 125,813,175

192 1 12,096 1 124,664,196

208 1.0833 13,104 .9914 123,592,823

224 1.1667 14,112 .9838 122,647,652

240 1.25 15,120 .977 121,801,960

256 1.3333 16,128 .971 121,048,783

272 1.4167 17,136 .9655 120,359,396

288 1.5 18,144 .9603 119,710,264

304 1.5833 19,152 .9552 119,079,911

320 1.6667 20,160 .9476 118,128,380

so if I got your explanation, if I increase my db_cache_size

from its current size of 200m to 320m, I will only see physical reads drop by about 6 million, or about 6 percent.

On the other hand, we have the memory to spare, so would it hurt to say, double the db_cache_size? The reason I ask is that even though my tuning reports say that the buffer cache hit ratio is in the upper 90’s, we have really wild dips throughout the day. If I use the OEM buffer cache hit % monitor, it will be cruising along near 100%, then it starts to look like my EKG while fleeing from an angry mob. It starts fluctuating wildly all over the chart. We have a few very large tables that are accessed throughout the day, and that data seems to blow everything else out of memory, and the hit ratio drops dramatically. Should I consider keeping that big table data in another pool instead? It would likely be pretty large, but how would I be able to see at any given time which objects have data in memory?

By the way, I ran the Oracle Expert Reports in OEM and it did not recommend any parameter changes, but I’m just a tad skeptical….

Two more facts:

NAME Shared Pool Size

—————— —————-

Database Buffers 201,326,592

Fixed Size 733,064

Redo Buffers 8,208,384

Variable Size 1,124,073,472

****************** —————-

sum 1,334,341,512

POOL NAME Free Bytes

———– —————— —————-

shared pool free memory 23,668,920

large pool free memory 32,571,392

java pool free memory 167,772,160

The java pool setting was required for last patchup, the docs warned that catpatch would not run properly if not at least 150m for java and shared pools.

Related: