Overlapped Recycling And SharePoint: The Generic Value Of Overlapped Recycling

Now that we have a good understanding of the two types of IIS Process Recycling I want to discuss the portion of the documentation that attempts to explain the value of process recycling. From my discussions with customers it appears that most people consider process recycling in general and overlapped recycling in particular only as a form of first aid. They also take this analogy one step further by assuming that it should only be enabled when the server is obviously sick and that a recycle event is evidence of some catastrophic failure that must be rooted out and repaired immediately. Let’s review the passage in the documentation that I believe sets this expectation:

 

Worker process isolation mode offers process recycling, in which IIS automatically refreshes Web applications by restarting their worker processes. Process recycling keeps problematic applications running smoothly, and is an especially effective solution in cases where it is not possible to modify the application code. [Emphasis mine]

This paragraph may lead you to believe that only problematic applications need process recycling. Unfortunately they don’t really define what problematic is. I suspect they meant applications suffering from prolific native memory leaks, managed code with poorly written object lifetime management, applications suffering from significant memory fragmentation, etc.

Am I suggesting that SharePoint is so riddled with flaws that we need to keep the virtual ambulance at the ready at all times? Not at all. As support people we should take every advantage to prevent the user from being exposed to the problems in the applications we support. This is the idea behind many common uptime oriented features, SQL clustering for example. I am saying that overlapped recycling represents one such opportunity and you should take advantage of it.

Overlapped recycling was created because applications sometimes have undesirable behaviors like memory leaks, fragmentation, etc. If you are running a client application like Word or Excel and it has these behaviors you can simply save your work and restart the application. With web based applications this is simply not a viable solution. There simply is no reasonable way to have everyone "save their work and restart."

Overlapped recycling provides an excellent compromise between the need to restart an application during production hours and the desire to shield users from the impact of doing it. In my opinion, if you are not taking advantage of this feature then you are just punishing your users and adminstrators needlessly.

 

Overlapped recycling in general is a good thing but too much of a good thing always ends up being a bad thing. If your worker process is recycling at a very rapid pace, say, several times a day or more, then you should be concerned and work to identify the root cause. If your worker process recycles once or twice a week due to the maximum memory used limit or the maximum virtual memory limit I would not be too concerned but I might start planning to add additional Web Front Ends to reduce memory pressure or start on the work to migrate to 64-bit servers.

 

In my next post I will be discussing: Overlapped Recycling And SharePoint: Why SharePoint Requires It