Filling the execution cache is an obvious job of the streaming service and is an obvious item to discuss. Since the obvious item is not as interesting as the un-obvious, deleting from the cache is covered in this post in detail.
Warning: Geek speak is turned on for this post. I hope people find it useful.
The Application Streaming client has the mission of maintaining its execution caches which support the execution of applications under Application Streaming. Yes, that’s rhetorical. The streaming client has the same cache management logic regardless of its execution platform and manages the cache in exactly the same manner for both server side execution and client side.
Most administrators understand pretty well that the middle layer of the isolation spaces represents the “installed application” and this layer is “not really present” at runtime. I’ve posted a few other blogs that show a graphic of this, so I won’t repeat it here but you should be able to find it up or down a few screens.
The installed contents (installation image) are presented to the application as if they are “present” and are only truly brought into the execution machine when the application actually “touches something”. That is, the arduous job of actually copying installation image content from the central server to the execution machine is put off until the last possible moment, or as a more elegant term, “just in time populated” into the cache. This is classic computer science stuff: If you put work off long enough, you may be able to avoid it completely. In college, I did my homework with this same methodology.
At runtime, the execution cache starts empty and grows and then retains its contents for future executions. The cache is maintained even across boots so that the later sessions will have execution content “already there” and avoid the need for a cache fill. Cache fills equal network traffic, equals slow, so we prefer to have 2nd time launch experience rather than a first time. Notice that cache fills are also shared across users. Consider a Presentation Server hosted execution where content is added to the cache for UserA. The execution cache is shared across the users, so the cache addition for UserA, will benefit UserB. The “first time launch penalty” of using streaming and isolation really applies only to the first user on the entire server, and there are ways to reduce that impact.
Deleting content from the cache
When running an unlimited number of different applications, for an unlimited number of potential users, from an unlimited number of separate streaming profiles, the streaming service must support them using finite space in which to run the applications.
How much space does it get?
What is the maximum size of the RadeCache?
The answer is … that it depends. The RadeCache limits are implemented as a size constrained high water, low water system where the low and high limits are determined at streaming client installation and possibly overridden by an administrator. The max size limit (high water mark) is installation time written to the registry and defaults to 5% of allocated disk space of the primary boot volume ( e.g. C: ), or a minimum of 1GB. The low water limit defaults to 95% of cache size.
Right – what does that mean?
The Streaming Service (RadeSvc.exe) keeps track of the space being used by the execution cache and where that value grows ABOVE the high water mark, the service unleashes a “purge thread”, or “delete thread” to free some space. Notice that it does not fail or even delay the cache fill for the application that triggered the growth beyond the high water mark. The application that is trying to run is immediately put back to doing useful work and this means that the cache is temporarily allowed to grow beyond the high water mark. The delete activity is done by the streaming service too, but it is done on a separate thread from the cache fill logic. The delete actions are also done at idle priority. The delete thread is persistent though and will continue chugging along until the deleting is finished.
The streaming service is aware of the cache contents of ALL of the execution caches and the size of each file in each target, and for each file, the age of when that file was most recently accessed. These execution caches are all of the subdirectories of \Program Files\Citrix\RadeCache. Notice that there can be many caches and even cache content for applications that are no longer published to any user that is presently logged onto that server or possibly even for applications that are no longer published to anyone anywhere. The point is that “new stuff” is more important than “old stuff” and eventually, the old stuff will age its way out of the cache.
If someone runs an application that uses old stuff, the old stuff is new again and is no longer the best candidate for erase. Low tech, but easy to implement which should read as “it doesn’t go boom”.
Low water mark
The cache manager delete thread repeatedly deletes old things from the cache until a “low water” mark is achieved. Once low water mark is achieved, the delete thread goes back to sleep. New cache fills can be occurring concurrently with cache deletes and all the while, the streaming service has to keep track of what is in the cache. This is one of the reasons that: If you want to purge things from the cache, you should use tools like RadeCache.exe to do the delete rather than just deleting the files. This lets the streaming service retain its self stated importance as the keeper of the cache and lets it know what is presently occupying space in the cache. Those are good things, but more importantly, it protects against windows in time where an application can start opening a file and then the file getting erased by the deleter before the file open has occurred. This would be a long aside, so I’ll get back on subject of deleting stuff from the cache.
Default low water mark is 5% below full. Strangely, it’s not implemented as 95% of full, which is bazaar, but that’s how it is. This value is configurable via registry, it defaults to “5” and you generally shouldn’t mess with it. If you do, understand that it is how much space should be FREE before the delete thread stops deleting stuff rather than the percent full after the deletion stops.
Low disk avoidance
In addition to filling the cache and deleting stuff from the cache, the cache manager also tries to notice when the disk is crazy full and takes steps to be a good citizen. The default here is 200MB. If you’re down to this limit of disk space, the cache manager will dispatch the purge logic to start freeing up space on the disk and otherwise to try to keep the machine from buckling. Once the minimum disk space is achieved, the delete thread goes back to sleep.
Notice that deleting stuff for purposes of managing the cache is a good thing. Deleting lots of things to help the system not run out of disk space is also a good thing. It’s possible though that all this good citizen stuff will result in endless cache deletes followed by fills followed by cache deletes, followed by fills, …
The cache manager includes thrash detection logic to prevent this scenario which says: If EVERYTHING in the cache was touched in the last 24 hours, then we’re thrashing, don’t delete anything. This may not be perfect – actually, it isn’t perfect – but it is an attempt to do the right thing and effectively support streamed applications while automating the cache cleanup.
Here are the registry keys that control the streaming service cache management. They are all items in HKLM\Software\Citrix\Rade
Product Architect, Application Streaming.
Citrix Systems, Fort Lauderdale, FL