My informal survey of hundreds of Citrix administrators over the years yields a “bell curve” for the answer to this question. The vast majority of our peers say they reboot their production Citrix servers every one, two, or three weeks; these are, after all, Windows servers. There are the few, at one tail end of the bell curve, that say they reboot their production Citrix servers every night. Some have apps with serious memory leaks and understand this; one person said if he has the third shift there to do it, he had several other good reasons besides memory leaks, to reboot the servers each night. On the other tail of the bell curve, there is our US Government’s CIA, and a tiny handful of others. The CIA says if there are memory leaks in their Windows applications, they have the resources of the Federal Government, to reverse engineer the app, throw it back in the vendor’s face, and say ‘this is ridiculous, just fix it!’, and so the CIA claims they reboot their servers ONLY for major Windows updates, and have no other mandatory reboot schedule implemented.
The actual Best Practice from Citrix is a different kind of “curve”: they say that the time to reboot a Citrix server will be whenever the “Committed Bytes” performance counter is “approaching” the “Available Bytes” performance counter. They draw a straight line across the top – “available bytes”, and draw a curve going higher and higher as time progresses – “Committed Bytes”.
As far as mechanism for reboot, if you have Citrix XenApp Enterprise Edition, you can set the reboot schedule easily in the Presentation Server console, by right-clicking the server object, and going to properties. There, Citrix recognizes the popular consensus, and offers options like “every 1 week”, “every 2 weeks”, or “every 1 day”, etc. They also offer options for sending out messages before reboots, in case you have a 24-hour shop.
What Citrix does NOT offer in this graphical utility is a way to conform to their own stated Best Practice – wait till the Available Bytes are approaching Committed Bytes, then reboot. Of course this might cause problems in the middle of a big work day, when just as everybody hits the server hard for a big deadline, the server decides it needs a reboot.
So the first thing we do is set it to what our peers have it set to – usually a once a week reboot, which is what we have at CNS. However, if things start getting slow, a quick check of performance monitor usually tells you that the Citrix server should have been booted a long time ago, as the two memory counters are riding along the top of the chart, indicating that “Committed Bytes” approached and then met with “Available Bytes” a long time ago.
When we see this, we need to schedule a reboot at the next possible opportunity, and possibly modify our reboot scheduling to be a little more often.