Overlapped Recycling And SharePoint: What To Watch Out For
The next section of the documentation on IIS Process Recycling that needs a little SharePoint context added is the section on “Considerations When Recycling Applications”. I believe this section may put a lot of people off of using overlapped recycling. Here is what it says:
When applications are recycled, it is possible for session state to be lost. During an overlapped recycle, the occurrence of multi-instancing is also a possibility.
Loss of session state: Many IIS applications depend on the ability to store state. IIS 6.0 can cause state to be lost if it automatically shuts down a worker process that has timed out due to idle processing, or if it restarts a worker process during recycling.
Occurrence of multi-instancing: In multi-instancing, two or more instances of a process run simultaneously. Depending on how the application pool is configured, it is possible for multiple instances of a worker process to run, each possibly loading and running the same application code. The occurrence of an overlapped recycle is an example of multi-instancing, as is a Web garden in which two or more processes serve the application pool regardless of the recycling settings.
If your application cannot run in a multi-instance environment, you must configure only one worker process for an application pool (which is the default value), and disable the overlapped recycling feature if application pool recycling is being used.
WOW! That’s is some scary sounding stuff, especially if you don’t even understand what “session state” and “multi-instancing” are.
If I didn’t know that SharePoint explicitly supports and recommends overlapped recycling I’d be a bit concerned about enabling this feature. Luckily for me, we recently published a set of recommended settings for configuring overlapped recycling on IIS Application Pools hosting SharePoint, you can find it here.
There is another thing you should be aware of when configuring overlapped recycling that they failed to mention in that documentation. You need to be absolutely sure you have enough free physical memory available to support multiple instances of the worker process.
For example if you are running SharePoint on a server with only 1GB of physical memory (the minimum) then you probably don’t want to enable overlapped recycling. The reason is that when a recycle event occurs, IIS is going to create a new worker process alongside your existing one. If your existing worker process has a working set of 650MB and you only have 180MB of free physical memory, then the creation of that second worker process is going to cause a significant amount of paging and greatly impact performance. You should use Performance Monitor to get a solid understanding of the memory requirements for your worker process. You can then use that information to determine if overlapped recycling is a viable choice for you. If you do not have enough resources with your current configuration I would suggest that it’s worth the effort and expense to upgrade you servers so you can take advantage of this great feature.
In the next post I will be talking about: Overlapped Recycling And SharePoint: Configuring The Shutdown Timeout