tags:

views:

1378

answers:

3

Is having to recycle an App-Pool in ASP.NET indicative of a larger problem in the Web-App? Or is this just 'the way things are' for ASP.NET and IIS?

Edit: Since one of the errors is an 'OutOfMemory' exception, what would be your suggestions for courses of action? Would you add memory? Profile the app? (It's important to note that I've got my own ideas on this, and have a path lined up, but would like to hear your answers).

+2  A: 

Personally, I think it's a sign of bigger problems. I have apps that run for weeks without recycling. The only reason they do recycle is because we push code updates. I think you should look into your event log to see if you can find any reason why the app pool is recycling. I've seen it happen quite often with memory leaks that will eventually cause you to run out of memory, forcing your app pool to restart.

Kibbee
+2  A: 

The health monitoring features of IIS enable automatic recycling of an app pool. So an app pool just recycling itself is not necessarily indicative of a problem; it could just be the preventive feature of IIS is turned on. The idea is that if your application has a memory leak or forgets to deallocate something, we can improve overall availability of the application by restarting it every so often, much like how you might restart Windows after it's been running on your desktop for a month and the net effects of small bad behaviors of many applications begin to take its toll.

In some other platforms, you might not notice these problems as quickly, especially in a CGI environment, since the whole framework is set up and then torn down with each page request.

Ideally, you would never have to restart the application pool, and having to do so is usually a sign of some sort of problem. The recycling feature is a sort of liability insurance against our own mistakes, or those "the planets just aligned just so" errors that are very difficult to track down, recreate, and happen so infrequently that they are probably not worth troubleshooting.

Nicholas Piasecki
And insurance against bugs in the framework as well.
tvanfosson
+1  A: 

There are alot of reasons an app pool can recycle. Unhandled exceptions, or threads hanging are a common cause. If you aren't closing all your SqlConnections and the connection pool is empty can cause it to recycle too. Deadlock timeout is another one, if you have a deadlock it will hang the worker process, and that will cause a recycle. Also, if IIS is using an abnormal amount of resources on the server, it will recycle (I think the default is 60%)

There are also alot of iis settings that will trigger it. There are settings to regularly recycle (in order to clear out session state), I think by default it is once every 24hrs. We have about 40 moderate to heavy public facing properties that we set to recycle during low periods.

I am pretty sure there are other reasons as well. People losing their sessions is probably better then the app crashing or the server hanging, which is why this is built in to IIS. Unfortunately, it can make it really hard to diagnose the problem. I would look at your event viewer around the time a recycle happens and see if there is anything interesting as a place to start. Keeping track of memory usage would be my next step, followed by some verbose logging.

Matt Briggs
Just to note -- one can work around the lost sessions problem by moving it out of process. The included ASP.NET State Server Windows service is the first step in that direction; the only gotcha is to make sure that everything that you shove in there is [Serializable].
Nicholas Piasecki