Comments on: Why Do We Recycle Our Application Pools?

By: Why does the IIS worker process recycle every 29 hours and not every 24 hours? - Admins Goodies

Wed, 11 Jan 2012 07:00:44 +0000

[...] site here [...]

By: Martin Lee

Martin Lee — Fri, 02 Dec 2011 10:13:00 +0000

The only logical conclusion I can come to is that it’s the first prime after 24, allowing it to have the least chance occurring in a regular pattern with any other server process; easing the investigation into problems. However, I may just be over-thinking it…

By: Yoda

Yoda — Thu, 01 Sep 2011 22:26:00 +0000

Where in the world did 29 hours come from?

Aliens!

By: הבלוגים של אורט » ארכיון » links for 2010-08-08

הבלוגים של אורט » ארכיון » links for 2010-08-08 — Mon, 09 Aug 2010 02:05:03 +0000

[...] Why Do We Recycle Our Application Pools? | The Inquisitive Coder – Davy Brion's Blog (tags: read) [...]

By: Bob

Bob — Tue, 20 Jul 2010 15:22:29 +0000

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?

By: Moshe Eshel

Moshe Eshel — Sun, 11 Jul 2010 20:26:21 +0000

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

By: Ian Rae

Ian Rae — Mon, 21 Jun 2010 21:30:37 +0000

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

By: Mahesh Velaga

Mahesh Velaga — Tue, 15 Jun 2010 18:06:15 +0000

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).

By: Anders Lybecker

Anders Lybecker — Mon, 14 Jun 2010 19:39:26 +0000

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…

By: Matthew Phillips

Matthew Phillips — Mon, 14 Jun 2010 14:11:00 +0000

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

By: The Morning Brew - Chris Alcock » The Morning Brew #620

The Morning Brew - Chris Alcock » The Morning Brew #620 — Mon, 14 Jun 2010 07:34:37 +0000

[...] 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) [...]

By: Vince

Vince — Mon, 14 Jun 2010 07:18:02 +0000

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.

By: Davy Brion

Davy Brion — Sun, 13 Jun 2010 20:31:40 +0000

@AdamR

i’d guess that’s only a minority of applications that suffers from that

By: AdamR

AdamR — Sat, 12 Jun 2010 20:43:56 +0000

Two words: LOH fragmentation

By: Davy Brion

Davy Brion — Sat, 12 Jun 2010 17:35:05 +0000

@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

By: Ayende Rahien

Ayende Rahien — Sat, 12 Jun 2010 17:25:39 +0000

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