Why Do We Recycle Our Application Pools?
Posted by Davy Brion on June 12th, 2010
I’ve never understood why IIS by default configures newly created application pools to recycle every 1740 minutes. That means that by default, our ASP.NET applications are restarted every 29 hours. And for what? Are we, the .NET community, so bad that we really can’t write code that can keep running without problems for more than 29 hours? Well, considering the overall lack of knowledge regarding memory management in .NET, i actually wouldn’t be surprised if that turned out to be the case for a very large portion of .NET development teams.
And indeed, if you browse the web to find the reason why application pools are configured to recycle automatically periodically, you’ll be hard pressed to find a reasonable answer that doesn’t pertain to memory issues. It’s like the community in general has pretty much accepted the fact that our web applications (or service layers hosted in IIS) will need to be recycled to avoid memory problems. To make things worse, i’ve frequently seen people discuss workarounds on how to keep things working properly after an application pool recycle in mailinglists for various projects. And again i ask myself: why?
I’ve always been of the opinion that if your code requires periodic restarts to keep working correctly, then something is clearly wrong. There is a bug in your code somewhere and you need to fix that, instead of restarting the process occasionally to make the problem ‘go away’. Guess what, it’s not going away, and if the load on your application increases, the problem will only pop up more frequently. So what are you going to do about that? Make the application pool recycle even more frequently? Put in another server to share the load? Perhaps we should focus more on fixing the actual code. You’re leaking resources somewhere, and that is what you need to fix.
In my company, it’s just standard procedure to disable application pool recycling on all application pools. Our applications simply have to keep working without application pool recycles. It’s that simple. If we run into a memory leak that causes problems, we focus on the actual problem and we fix it. We’ve ran into plenty of memory leaks (though it hasn’t really happened a lot in the past year, guess why?) and we’ve fixed each and every single one of them that we’ve ran into. Side note: i’m talking about .NET code that is running on the server. While i’m pretty sure that we do better at memory management in our Silverlight clients than most other Silverlight-using-shops do, you just never know for sure with Silverlight, partly because there are so many memory leaks in Silveright itself. But for .NET code running on a server, a memory leak is simply inexcusable in my opinion. I mean, it can happen to the best of us (i’m pretty much responsible for most of ours to be honest), but it’s not about who introduced the memory leak. It’s all about how you deal with it. And recycling the application pool periodically is not dealing with it, it’s living in denial.
The only viable reason to recycle application pools that i can think of is in the situation of a shared hosting provider. If you’re offering shared hosting, it only makes sense to recycle application pools occasionally since it’s quite realistic to assume that most of those application pools will not be in use constantly. If a pool is recycled, it will not consume any resources until the next request for an application in that pool is received. In the context of shared hosting, that actually makes sense. In the context of real applications, that makes little sense unless you’re hosting a lot of them and plenty of them are hardly being used. Still, is that really a good enough reason to enabling application pool recycling by default? I obviously don’t think so.
In my opinion, we, as a community, really need to start focusing more on memory management in .NET and on making sure that our applications can keep running without problems.
June 12th, 2010 at 6:25 pm
You aren’t looking at things in the proper historical context.
Most of the code that run on IIS up until IIS 6 was unmanaged code (VBS + COM).
That was _rife_ with memory leaks.
Beside, it significantly reduce support calls, because a LOT of problems go away after a restart, it make sense to schedule a restart every now and then to clear things
June 12th, 2010 at 6:35 pm
@Ayende
the historical context is not really relevant… i still see no reason to do it _today_, so what happened before IIS6 shouldn’t matter. The field of software development is supposed to advance all the time, so sticking with decisions from the past is not necessarily the right thing to do.
“Beside, it significantly reduce support calls, because a LOT of problems go away after a restart, it make sense to schedule a restart every now and then to clear things”
that just sounds like laziness or even negligence
June 12th, 2010 at 9:43 pm
Two words: LOH fragmentation
June 13th, 2010 at 9:31 pm
@AdamR
i’d guess that’s only a minority of applications that suffers from that
June 14th, 2010 at 8:18 am
Recycling App Pools is pretty standard when dealing with SharePoint. SharePoint still uses unmanaged code. Joel Oleson recommends a nightly recycle: http://blogs.msdn.com/b/joelo/archive/2007/10/29/sharepoint-app-pool-settings.aspx
And just because a SharePoint object implements IDisposable doesn’t mean you should actually .Dispose() of it: http://msdn.microsoft.com/en-us/library/aa973248%28office.12%29.aspx. You can run their SPDisposeCheck ’til the cows come home and still encounter leaks.
So like you’ve said, there must be something clearly wrong … with SharePoint.
June 14th, 2010 at 8:34 am
[...] Why Do We Recycle Our Application Pools? – Davy Brion argues that we as .NET Web Developers need to spend more time focusing on Memory Management to ensure that our applications behave correctly at all times, and therefore remove the need for application hosts such as IIS to restart every 29 hours (by default) [...]
June 14th, 2010 at 3:11 pm
Of course we should not.
But if we are obliged rely on 3rd-party code which has leaks, and for which fixes are unavailable we may have no choice.
Luckily I am not in that position any more
It seems the default is chosen (as usual) to help prop up the less knowledgeable members of the community
June 14th, 2010 at 8:39 pm
I agree that developers and the community should focus on quality software including proper memory management.
I have seen same sluggishness in console apps and windows services. Auto restart is just enabled…
June 15th, 2010 at 7:06 pm
I have seen mixed opinion on this.
But, the point to note here is to concentrate on memory leaks irrespective of whether your app is periodically recycled or not (just not relying on recycling to magically fix your memory issues).
June 21st, 2010 at 10:30 pm
The QA answer to this issue is to say that “we in QA only tested the server for an X-day day longevity test, therefore we cannot guarantee what might happen after that. If you want Y days then add that to the test plan”.
This only applies if you’re shipping a software product. If you’re managing your own servers then you have a permanent longevity test running
July 11th, 2010 at 9:26 pm
I assume most developers and development teams (I know my team is there at the moment) are at a place were they struggle to keep up with the demands and keep the application in a working state. At this stage it is logical to “resolve” memory leaks with the recycle “solution”… agreed it is not a good solution, since it doesn’t solve the problem. but it does keep the application in a reasonable state.
In my previous job, we took the time to do code maintenance every now and then, to fix exactly these sort of problems (enhance memory management, reduce leaks, and cache/un-cache objects according to usage patterns and stats) – however, I don’t remember ever getting to a point where we give app the daily recycle that was configured (we never even tried to survive without it – we just configured it and forgot about it), we did have to invest some time to make sure that the application loads correctly after the recycle event.
I agree that in an ideal world – we should invest a lot of time trying to perfect our app, but in the given situation (small R&D team trying to make something new and innovative – stability and perfection are often fall to the TODO in the future list.
I must say that personally I strive to write good code (I’m now reading “CLR via C#” in an attempt to broaden my understanding to a level were I can understand even better why a coding technique is better for me – and I’m enjoying the learning, lots of good info in this book). But honestly, most of the time, I’m just happy I managed to make it WORK in time.
I hope this makes sense,
Moshe
July 20th, 2010 at 4:22 pm
The real question is why 1740 minutes? I had assumed erroneously that IIS 7 creating an application pool of type “Integrated” would not set a default recycling policy, so I never thought to look. I hunted through the application and fixed a number of issues only to discover that 29 hours would more or less randomly drop the internal state in the middle of the business day!
Why not 24 so there is an obvious pattern? Why not default to 3:00 AM? Where in the world did 29 hours come from?
August 9th, 2010 at 4:05 am
[...] Why Do We Recycle Our Application Pools? | The Inquisitive Coder – Davy Brion's Blog (tags: read) [...]