Reason for Shutdown: HostingEnvironment

[Robert Dunlop]

In my Application_End method in Global.asax, I log the shutdown reason
(System.Web.Hosting.HostingEnvironment.ShutdownReason) and any errors
returned from Server.GetLastError(). Occasionally (2-3 times a day) I get a
shutdown for reason HostingEnvironment, with no errors.

Can anyone tell me what this is about?

(I'm running ASP.NET 2.0)

 

[Mark Fitzpatrick]

Hi Robert,
The Application_End event will fire whenever the application is shut down,
which you already know. There are reasons why the application will shut down
that have nothing to do with errors. The first is that simply nobody has
visited the site in roughly 20 minutes. Usually this period of time
corresponds to the session timeout value. So, 20 minutes after the last
person's session has been destroyed due to inactivity, the application is
shut down to perform garbage collection and regain resources (not to mention
just to keep an unused application off the system until it's needed again).

The second reason is the application pool has recycled. This means that the
system has hit a wall with regards to the amount of memory that the
application can use and needs to be shut down, perform garbage collection,
and restart with fresh resources.

In my experience, neither of these conditions will result in an error since
they are technically normal operation of the server.

 

[Robert Dunlop]

Thanks for your quick reply Mark.

Indeed, I had noticed that many of these shutdowns occurred after a period
of inactivity that seems to correspond with the session timeout I've set.
However, there are definitely times when this occurs during periods of
frequent activity, even with the relatively long timeout I've set.

A couple of questions regarding the second reason you presented:

1. This application is on a hosted solution (GoDaddy), so there are likely a
number of other applications on the server. When you say it is recycling
the application because it has hit a wall, do you mean that the resource
usage of my application has exceeded quota, or would this also happen
because of a system-wide condition?

2. I would like to take some metrics of my application's use of resources to
make sure I don't have a leak going on, but because I am on a shared host my
options seem to be limited. I have managed to access static methods of
ThreadPool to check on our thread usage, because I was concerned about our
use of a one-way web service to perform long running background tasks, but
I've never seen available threads drop below 395 out of 400, so I'm not
eating up the thread pool. What other metrics might I be able to attain in
a restricted environment, in particular I would like to get an idea of what
our memory footprint and CPU time are about. Unfortunately, all attempts
I've made to access the performance counters seem to be blocked, so that
route is out.....

Thanks for your help.

 

[Mark Fitzpatrick]

Hi Robert,
It could be system-wide, it depends upon what other applications are in the
application pool. It could be that your application is sharing a pool with a
number of other sites. If that's the case, when overall memory usage exceeds
a certain amount, the pool will recycle. It could also recycle because of
some error that is corrupting things too much so the pool recycles to repair
it. I would say it would be more apt to be a memory issue. I have little to
no faith in GoDaddy's hosting though. They are the single largest source of
hosting issues for the FrontPage community and their support is rubbish and
has absolutely no clue. It wouldn't surprise me if they have everyone thrown
into the same pool together and the pool is just hitting a memory threshold
occasionally. The pool should also be set to recycle after X minutes,
usually about every 30 hours or so I think.

I'm not sure what other options are open as far as performance metrics if
you don't have access to the performance counters. You can probably get a
fair idea running the performance counters locally and beat on the app for a
while.

One of the biggest performance hits to make sure you're not doing is
publishing the site as a debug build versus a release build. Also setting
the debug="false" attribute of the compilation element of the web.config.
It's easy to forget it's set to debut and that will increase the footprint
of your app as it brings in other resources that wouldn't be needed with
release.

 

[Robert Dunlop]

Hmmm, I had replied the other day, but it seems never to have shown up in
this thread - let me try this again:

Thanks for your quick reply Mark.

Indeed, I had noticed that many of these shutdowns occurred after a period
of inactivity that seems to correspond with the session timeout I've set.
However, there are definitely times when this occurs during periods of
frequent activity, even with the relatively long timeout I've set.

A couple of questions regarding the second reason you presented:

1. This application is on a hosted solution (GoDaddy), so there are likely a
number of other applications on the server. When you say it is recycling
the application because it has hit a wall, do you mean that the resource
usage of my application has exceeded quota, or would this also happen
because of a system-wide condition?

2. I would like to take some metrics of my application's use of resources to
make sure I don't have a leak going on, but because I am on a shared host my
options seem to be limited. I have managed to access static methods of
ThreadPool to check on our thread usage, because I was concerned about our
use of a one-way web service to perform long running background tasks, but
I've never seen available threads drop below 395 out of 400, so I'm not
eating up the thread pool. What other metrics might I be able to attain in
a restricted environment, in particular I would like to get an idea of what
our memory footprint and CPU time are about. Unfortunately, all attempts
I've made to access the performance counters seem to be blocked, so that
route is out.....

Thanks for your help.