I initialize static state of my web applications in Applications_Start method (Global.asax). At that time I write a message to log. Suddenly I've realized that this method was called every 10 minutes.
Is it corrected behavior? I expected ASP.NET to keep its applications at least for several hours.
Your expectation is incorrect. This is set in the application pool setting in IIS configuration. I think the default is 20 minutes. This can be changed to 0 if the application pool should not be recycled.
This is not typical. Something is causing it to restart and it should not be doing so this frequently. Check out How to find out why an ASP.NET web application is being restarted question to see how you can log details on why it restarted.
Since you are writing out log files, maybe you are writing them to a location that is be monitored for recompilation, which will cause a appdomain restart. Check out the post What causes an application pool in IIS to recycle?
Check out this article on iis.net to see the default for recycleing. It is 29 hours, so unless this setting has been changed for you, something else is causing it, not the automatic recycle.
Related
I have an asp.net app on IIS 7. It is 'pre-compiled', but I understand that IIS must still compile the assemblies the first time they're run.
Here is the problem--After I publish and deploy the application, I log in, and (as expected) it takes about 30 seconds to see the login page. Then I visit every page so that they are compiled (I have used the 'individual file for each page' or whatever option).
So far so good.
Then 10 minutes later i log in and it's near instantaneous. Still good and expected.
Yet the next day, my first logon takes 30 seconds or more again. Nobody changed web.config or copied any new assemblies in the meantime--this I am sure of.
Does anyone have an idea why this is happening? Is there an application timeout (as opposed to a session timeout)? Is there some setting in IIS admin console that I may have left at some default that is not optimal?
Thanks for any help on this,
James
Yes, starting an ASP.NET application in IIS is relatively slow. How much? It depends...
It's slow again the next day because IIS shuts down apps when they are inactive for some time.
The solution is "Application Initialization". This is built-in in IIS 8 and available out-of-band as a module for IIS 7.5:
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
There is an Idle Time-Out on the Application Pool under Advanced Settings. Set this to 0 and the application will not stop due to inactivity.
We are encountering a strange phenomena in our production environment, every few hours the application kicks all users out by ending their sessions with Session_End event and fires Application_End event.
In our log, all the user's sessions are closed on the same mill-second.
We encountered this problem in our Test environment but only on rare occasions, and we could not duplicate this.
Everything else seems fine, other application running on this server works fine, there is no memory leak or CPU overuse. The application is based on ExtJS version 3.3, NHibnernate 3.2 and ASP.NET 4.0.
It doesn't seems like a Timeout error, some of the users worked for only several minutes before the session end.
Has anyone encountered similar problems?
There are a couple of reasons why an application pool recycles (and thus ends all open sessions and ends the application). See http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx for a complete overview.
We had a similar problem in a production environment once. The reason for the recycle was the virus scanner that touched the web.config on each scan which made the application pool recycle. Try to disable the virus scanner on the server or exclude the application directory in the virus scanner.
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
This post: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx gives you a way to catch the application end event with more detailed logging. This might help you to find the cause of the recycle.
Having a bit of a problem with my hosted ASP.NET applications. I noticed slowness when opening pages, the kind of slowness that you see the first time you start up an ASP.NET app. After researching, I'm finding that the Application_End event is firing shortly after the application starts, apparently killing the sessions, static values, etc.
I have the standard default web.config set up, and I am writing to the session when a page is requested. But for whatever reason, the application isn't waiting 20 minutes (or whatever the default is) before dying - sometimes it's just a minute or two, sometimes even less.
Of course, this doesn't happen locally in my dev environment - everything works as expected, with identical code and web.config values.
There is only one server, so no farm or anything like that.
I know that there are many things that cause an ASP.NET app to end - IIS restarting, app pool recycling, DLL or config file modified, reboot, etc. But I'm hoping to have a better guess when I report this to my hosting company, to help research and fix the problem. The server isn't being rebooted, and I'm not modifying any files, so that seems to leave IIS or the app pool restarting, unless I'm missing something else.
IIS restarting is in the Windows Event Viewer, so that's easy enough to find. Assuming that's not it, is there any way to determine exactly why the app keeps resetting?
Any thoughts you may have on this would be appreciated.
This is some of the reason that you may think and check for.
a command that shut-down the app.
a bug/closed loop that crash the app.
a memory limit on the application pool that shut-down the app. (this is the most possible)
a very bad iis and pool configuration on a shared server or on a virtual server. Maybe too many sites on the same iis, and at the same time a bad pool setup ?
You can check for bugs on the global.asax
void Application_Error(object sender, EventArgs e)
{
}
by log all of them and check them out.
You can check the pool setup if you have access on the iis, or ask from the administrator to check it for you and remove the memory restart limits.
I am running an ASP.NET application on an IIS7 server. It has been running fine for a long time, but over the past week or so it has been discarding all users' sessions several times a day. I enabled all of the application pool recycle logging options as described in http://blogs.iis.net/ganekar/archive/2008/12/12/iis-7-0-application-pool-recycles-log-a-event-in-windows-event-log.aspx, but I didn't get anything in my event log.
There are no errors in the event log, and no visible symptoms except that all my users lose their sessions.
Are there any other reasons that IIS would recycle my application pool? Is there any other type of logging that I can enable to find out what is happening?
When you experience this behavior, how recently have you done a deployment of your files to the server?
There is a nasty configuration option called numRecompilesBeforeAppRestart on the compilation tag:
<system.web>
<compilation debug="true" numRecompilesBeforeAppRestart="15">
http://msdn.microsoft.com/en-us/library/system.web.configuration.compilationsection.numrecompilesbeforeapprestart.aspx
This value defaults to 15. I've been through an application killing all user sessions before and this was the culprit for me. For roughly a day after a lightly used web application was updated (new files copied to the server; this ended up overwriting EVERY file, numbering into the hundreds), we'd get constant AppDomain restarts evidenced by all Session values for all users disappearing.
I found this bug report listing the behavior I'm experiencing:
http://support.microsoft.com/kb/319947
Here is the really important relevant text to my scenario:
However, this problem occurs when you
load many new .aspx or .ascx files to
the server (for example, 61 files).
The server unloads the application
when the first 15 files are recompiled
and every time another 15 files are
recompiled until the server reaches
61. This results in four application restarts even though only one is
required.
I switched the value to 99999 and the problem went away. This means more memory will build up in my worker process, so I added a daily recycle (3am when my site has no users) to the IIS AppPool recycle settings.
You can set options in the metabase to log the different types of recycle events to the event log.
For IIS 6.0, see http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/87892589-4eda-4003-b4ac-3879eac4bf48.mspx
For example, to enable logging of recycle events due to exceeding the private memory limitation, execute this on your web server:
cd %systemroot%\inetpub\adminscripts
cscript.exe adsutil.vbs set w3svc/AppPools/YOUR_APP_POOL_NAME/AppPoolRecyclePrivateMemory true
Here is a link to [different] instructions for IIS 7.0: http://technet.microsoft.com/en-us/library/cc771318%28v=ws.10%29.aspx
We run a .NET 1.1 application on W2k3 server. The app pool is configured to recycle at 512MB. However, a week ago it started to recycle every 2 minutes. Since we run a web farm, the anonymous user we run IIS with is a domain account.
About a week ago, that user account expired, and we have to re-enable it. Could that have caused any problems? Maybe that user lost some permissions, or was left out of the IIS_WPG group.
Any advice will be greatly appreciated.
Try finding out more info by Logging ASP.NET Application Shutdown Events
Look in the server's Event Log. That may hold the answer.
If after checking the logs and all the standard "App Pool Health" settings (the obvious), I would look for other processes that might be mucking around with your web.config file (check the timestamp on it), which of course causes the app to restart.
I was once at a customer site and we couldn't figure out why our app kept restarting (and dropping all session state, etc...) Turned out it was a broken "Auto-Encrypt All Web.Config Files" little script that they had scheduled to run every 5 minutes. Problem was it never properly detected that it successfully had encrypted the file, so it just kept rewriting every 5 minutes... sigh..