Why does IIS default to recycle the app pool after a given time? Is there some specific reason other than perhaps most web apps are not managing the memory prudently? Given that you are managing your application's memory properly, is is safe to go ahead and turn this off? What are some potential down sides, up benefits to turning off recycling or keeping it on?
Asked
Active
Viewed 2.5k times
24
-
1are you sure you don't mean recycling the worker process, not the app pool itself? – Ryathal Mar 28 '12 at 15:18
5 Answers
17
Yes, the reason it defaults to once a day is out of a worry that the web app could have a memory leak. The biggest downside to frequently recycling IIS app pools is that it will cause web.config reading, assembly loading, and a recompilation of asp.net pages and (if you don't believe in pre-compiling them) code behinds. This is a rather heavy process and it doesn't occur until the next request for a page after the app pool has recycled, greatly slowing down that particular request. IIS7 now has a module you can download called Application Warm Up to help "deal" with this issue.
I personally prefer to use memory-based maximums coupled with logging on app start rather than scheduling my recycling. This allows me to assume my app has no memory leak and be proven wrong when the app pool recycles.
Randolpho
- 271
- 1
- 5
-
+1, but it looks like they've [taken down](http://forums.iis.net/t/1176740.aspx) the application warm up module – aceinthehole Mar 28 '12 at 17:24
-
what? That's hilarious. Maybe they'll figure out a better solution some day. :/ – Randolpho Mar 28 '12 at 19:03
-
3
14
1740 minutes is 29 hours:
Back when IIS 6 was being developed—which is the version that introduced application pools—a default needed to be set for the Regular Time Interval when application pools are automatically recycled.
Wade suggested 29 hours for the simple reason that it’s the smallest prime number over 24. He wanted a staggered and non-repeating pattern that doesn’t occur more frequently than once per day. In Wade’s words: “you don’t get a resonate pattern”. The default has been 1740 minutes (29 hours) ever since!
Geoffrey Huntley
- 241
- 2
- 3
8
Feature is a holdover from classic ASP days when everything leaked memory and you had to do it. Most folks had a scheduled restart on the web server overnight. IIS6 automated this with app pool shutdowns every 1740 minutes (or if app is idle for 20 minutes). IIS7 continued the tradition.
Advice I got from microsoft back in those days was that this was unnecessary unless you had a legacy app with a known memory leak. So if you were running purely managed code you would be OK.
Wyatt Barnett
- 20,685
- 50
- 69
4
Shut it off and monitor the app pools. Most complex enterprise applications use lots of legacy code and much of that code is kinda leaky. So for most installs having the app pool restart occasionally is not a bad idea.
There are other options like monitoring the time of inactivity that may be a better solution for your situation.
Spinning up an app pool can take some time and make the application less responsive so keeping them up can help performance.
ElGringoGrande
- 2,913
- 22
- 20
1
Indeed, this is purely to clean up leaked resources that (might) be present. The 1740 minutes is not the only triggering event either. It also happens after a specific maximum number of requests or after exceeding a specific amount of worker process memory. It is pretty well documented in the MSDN library. Unfortunately, this policy breaks things like session state and statics such as singletons. Your app will need to be robust enough to re-authenticate users and/or re-initialize singletons as needed to avoid disturbing your user's experience. It forced us to manage authenticated sessions in the database rather than in the ASP.NET session. Otherwise, our users were booted back to our login page whenever the server recycled due to one of these triggers.
Larry Hector
- 93
- 5