7

In the past 2 weeks, our nightly IISReset has not come back up successfully and caused us an outage.

We have a Windows Task that runs every night that executes an IISReset, and I'm wondering if this is even necessary anymore?

Should I be looking into the functionality in the app pool to restart itself instead?

Improve this question
2
  • 6
    Fixing a problem instead of fixing THE problem. My suggestion would be to fix the problem that the nightly resets is intended to ameliorate.
    – joeqwerty
    Jun 9, 2015 at 14:21
  • 1
    I think IIS was fixed since the year 2000 or so when a daily reboot was mandatory...
    – Alexis Wilke
    Jun 10, 2015 at 6:31

3 Answers 3

Reset to default
25

I wouldn't consider it a good practice. When most people usually set up things like "nightly iisresets" or "nightly reboots," generally, it's because they are running an application that is poorly-written and leaks resources, to the point where the entire system may become unstable unless we restart the application, the service, or even entire system. The thing is, those people are ignoring the actual problem. (Or are unable to fix it.)

Fix the application to be stable and not leak resources, and then iisresets or system restarts will no longer be needed or helpful. Unfortunately, this is very prevalent with IIS web apps, to the point where IIS itself is designed around the idea that the applications it runs will be poorly-written and leaky. Otherwise there'd be no need to routinely recycle app pools, etc.

So to recap - if nightly iisresets are part of your strategy, it's because you have a poorly-written web application and the ideal thing to do would be to fix your app. (And yes, recycling app pools is better than an iisreset, as you can recycle an app pool without affecting every other website on your server.)

Edit: Here's a pretty neat blog post from a guy who basically says the same thing that I did, but he also claims that he always completely disables app pool recycling altogether, instead insisting that his team fix each and every last memory leak, which IMO is a pretty heroic and laudable effort:

http://thatextramile.be/blog/2010/06/why-do-we-recycle-our-application-pools/

Improve this answer
3
  • 2
    Fixed yer wall o' text. Hope you don't mind. :)
    – EEAA
    Jun 9, 2015 at 13:42
  • 7
    Last time I did something heroic and laudable, my then-coworkers "unfixed" it :(
    – Mathias R. Jessen
    Jun 9, 2015 at 14:32
  • I disagree that it's heroic. It is standard operating practice everywhere I have ever worked, or run.
    – user207421
    Jun 10, 2015 at 12:04
8

Yes, totally outdated, in fact it was never ever required or good practice. If you had to do this there was something wrong with your application.

Recycling application pools is a much cheaper operation as it just shuts down one process and starts another one. Iisreset restarts the whole IIS with all its components.

AppPool recycling also gives you much more granularity on when to restart your pool depending on various metrics.

Improve this answer
3

I would like to offer an alternative view on this. Whilst I agree that you shouldn't do it because you are trying to solve an issue such as resource leaks, we randomly destroy machines during office hours. The idea being that we ensure our automatic disaster recovery plan works and if it doesn't it fails during the day when we have most of our staff in. We always have a few servers that are not affected by this to ensure that we keep a minimal service however we are safe in the knowledge that if we do have to do a reboot on a server we feel safe to do so. If you don't do one regularly and all of a sudden you have to do a system restart for what ever reason it can be a very stressful and nervous time as who knows what's going to happen.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .