Common reasons why your application pool may unexpectedly recycle


If your application crashes, hangs and deadlocks it will cause/require the application pool to recycle in order to be resolved, but sometimes your application pool inexplicably recycles for no obvious reason. This is usually a configuration issue or due to the fact that you’re performing file system operations in the application directory.

For the sake of elimination I thought I’d list the most common reasons.

 

Application pool settings

If you check the properties for the application pool you’ll see a number of settings for recycling the application pool. In IIS6 they are:

  • Recycle worker processes (in minutes)
  • Recycle worker process (in requests)
  • Recycle worker processes at the following times
  • Maximum virtual memory
  • Maximum used memory

These settings should be pretty self explanatory, but if you want to read more, please take a look at this MSDN article

 

The processModel element of machine.config

If you’re running IIS5 or the IIS5 isolation mode you’ll have to look at the processModel element. The Properties you should pay the closest attention to are:

  • memoryLimit
  • requestLimit
  • timeout

memoryLimit

The default value of memoryLimit is 60. This value is only of interest if you have fairly little memory on a 32 bit machine. 60 stands for 60% of total system memory. So if you have 1 GB of memory the worker process will automatically restart once it reaches a memory usage of 600 MB. If you have 8 GB, on the other hand, the process would theoretically restart when it reaches 4,8 GB, but since it is a 32 bit process it will never grow that big. See my post on 32 bit processes for more information why.

requestLimit

This setting is “infinite” by default, but if it is set to 5000 for example, then ASP.NET will launch a new worker process once it’s served 5000 requests.

timeout

The default timeout is “infinite”, but here you can set the lifetime of the worker process. Once the timeout is reached ASP.NET will launch a new worker process, so setting this to “00:05:00” would recycle the application every five minutes.

Other properties

There are other properties within the processModel element that will cause your application pool to recycle, like responseDeadlockInterval. But these other settings usually depend on something going wrong or being out of the ordinary to trigger. If you have a deadlock then that’s your main concern. Changing the responseDeadlockInterval setting wouldn’t do much to resolve the situation. You’d need to deal with the deadlock itself.

 

Editing and updating

ASP.NET 2.0 depends on File Change Notifications (FCN) to see if the application has been updated. Depending on the change the application pool will recycle. If you or your application is adding and removing directories to the application folder, then you will be restarting your application pool every time, so be careful with those temporary files.

Altering the following files will also trigger an immediate restart of the application pool:

  • web.config
  • machine.config
  • global.asax
  • Anything in the bin directory or it’s sub-directories

Updating the .aspx files, etc. causing a recompile will eventually trigger a restart of the application pool as well. There is a property of the compilation element under system.web that is called numRecompilesBeforeAppRestart. The default value is 20. This means that after 20 recompiles the application pool will recycle.

A workaround to the sub-directory issue

If your application really depends on adding and removing sub-directories you can use linkd to create a directory junction. Here’s how:

  • Create a directory you’d like to exclude from the FCN, E.g. c:\inetpub\wwwroot\WebApp\MyDir
  • Create a separate folder somewhere outside the wwwroot. E.g. c:\MyExcludedDir
  • use linkd to link the two: linkd c:\inetpub\wwwroot\WebApp\MyDir c:\MyExcludedDir
  • Any changes made in the c:\inetpub\wwwroot\WebApp\MyDir will actually occur in c:\MyExcludedDir so they will go unnoticed by the FCN.

Is recycling the application pool really that bad?

You really shouldn’t have to recycle the application pool, but if you’re dealing with a memory leak in your application and need to buy time to fix it, then by all means recycling the application pool could be a good idea.

 

What about session state?

Well, if you’re running in-process session state, then obviously it’s going to be reset each and every time the application pool is recycled. If you need to brush up on your state server options, then I recommend taking a look at this entry.

Later! / Johan

Comments (10)

  1. This is something me and my colleagues come across quite often. It is often quite time consuming to troubleshoot,

  2. MA says:

    Thanks for your wonderfull articles.

    For the last couple of hours, i have been digging the following issue.

    I’m getting " System.NullReferenceException" at a locations i the code that shouldn’t give that.  I.e I’m not using objects that are null or anything that can give this.

    The only way out, is to recycle the Application pool.

    I look at the stack trace and it’s pointing to code that is ok(i.e I’m not using objects before i initialize them).

    Any idea what’s causing the Application resources to hang and require recylce?

    Thanks

  3. Jeanine says:

    MA – what did you find on your system.nullreferenceexception? We have been battling this same issue for months!

  4. yaghi says:

    check if the initialized objects are disposed or you are using them correctly

    posting the sode could help

  5. amar says:

    Hello

    Here  in the above description ,you have suggested way to link directories..in Heading "A workaround the sub-directory issue"

    I want to know how to link…how to use the command linkd…

    where to write the command……linkd.

    In my application……..reports are generated and displayed in a grid ..on a webpage…….Many sql queries are fired to create that report…

    The application recycles …because of it…….what may be the reason for it.  is my aspx page is changing…….or is running out of memory…

    Its creating a big problem as the user is continuosly logged out..on report viewing….

  6. amar says:

    what do u mean by updating the aspx file…………

    adding a control …etc.

    this would help me to understand .the reason behind my application recylces..

  7. JohanS says:

    I mean physically alering it in any way. Anything suggesting to the OS that the file has been touched will trigger a File Change Notification. Some Anti Virus software might even cause this without actually changing the file.

    / Johan

  8. John Saunders says:

    Is there some logging or tracing method that will tell you which of all these reasons caused the recycle? I'm asking about IIS 6, though an IIS 7 answer would be helpful also.

  9. Nam says:

    I have an ASP.NET MVC 4 app integrated with legacy ASP.NET 4.0 WebForm app. The session timeout on the web.config file is set to 10 hours. The app has the Forms authentication implemented. The web forms of the app do not expire before 10 hours but the pages on the MVC part of the app (.cshtml files) expire after every 20-30 minutes. What could be the reason and how can we resolve the issue.

  10. BlueSky2010 says:

    Great article – thanks Johan!