We have two applications - WebAPI and WCF service. Our WebAPI is consuming WCF service.
We have two different app pools for both applications with different recycle settings:
wcf application recycles every day at 1 am fixed with overlapping sessions.
webapi has default recycle settings.
We are getting wierd IIS restart daily at 1 am.
No event is logged in Event Viewer.
Note: We have grafana setup to monitor server and it sends alert daily at 1 am for server down.
What could be reasons for IIS restart?
have you seen application pool recycle in event log? as you know when recycling happened , all session in iis will destroy and a log wrote in Windows event log. so I need to send deliberate information about what you detect in your monitoring application. this is because of it might a false positive of your monitoring application. as you mentioned it didn't logged in event log, I suspected this problem Is for that. please send practical information to solve your problem.
It might be your application cannot refresh the app pools when you set their app pool refresh to happen at 1am.
I would look at the permissions given to the application pool. It could be the permissions aren't enough to restart it.
Other than that I would also recommend enabling Logging. You will find out your problem with Logging enabled.
Look through the application pool settings under advanced setting and ensure Recycling > Generate Event Log Entry is set to true for all the entries. This will ensure everything related to the application pool will be logged and you will be able to see the reasons for the recycle.
Related
We have a site that keeps falling to sleep, which causes an error due to the time-sensitivity of our sporadic requests.
I've seen how there is an "Always On" setting in the old Azure console, but it doesn't appear to apply to the new interface:
How to prevent an Azure website from going to sleep?
Where is this setting now, or how do I do the equivalent?
Here's what I see:
There's a couple of options. One of those is to use Traffic Manager Endpoint Monitoring which keeps calling your app so it doesn't recycle. Or is automatically started again when it does.
According to the blog post Windows Azure WebSites and Cloud Services Slow on First Request you can "include a script with your package, which is configured to run as a startup script, every time the role is restarted."
REM *** Prevent the IIS app pools from shutting down due to being idle.
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00
REM *** Prevent IIS app pool recycles from recycling on the default schedule of 1740 minutes (29 hours).
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.recycling.periodicRestart.time:00:00:00
How to proceed with the configuration can be found under "Avoid automatic recycle of Azure Cloud Services Web Role" of that post.
Check the Cloud Service availability on Azure portal.
Ensure that all role instances are in a Ready state. If they are not,
refer to the troubleshooting blade.
RDP into the role instance and check the IIS process (w3wp.exe) in
Task Manager is running.
If the w3wp.exe process does not show in Task Manager, go to IIS
Manager and restart the application.
Check the http response code you get in the browser. 50x errors are
application-related issues, refer to the troubleshooting blade.
Check that the default ports 80 (for http) and 443 (for https) are
accessible. Use TELNET or TCPING to ensure that the w3wp.exe process
is listening on it.
If your web application is accessible locally but not externally, it
could be a network-related issue.
You may want to refer this as well.
I am trying to track down some issue where users will randomly get prompted by IIS 7.5 for their security credentials. I have come across something in the Event Viewer that says
A worker process with process id of 'xxxx' serving application pool 'MyAppPoolName' was shutdown due to inactivity. Application Pool timeout configuration was set to 20 minutes. A new worker process will be started when needed.
So let's say that happens, and then a user comes in and hits the site. A new worker process gets started. Could this cause a prompt for credentials from IIS? I am using Windows Authentication with IIS.
The application pool will recycle after a configured amount of inactivity. If your session timeout is larger than the IIS recycle time then you are at the risk of losing sessions if you are using in-process session state. Normally, IIS will attempt to hang onto sessions created prior to a recycle and process new requests using the new thread pool.
Configuring the application to use the ASP.NET State Service or sql server to hold session state will allow the sessions' to be maintained during recycle. However, the initial request after the recycle event that you are seeing in your log will take a startup penalty.
I would configure the session timeout to be less than the recycle period in IIS, however in a properly configured application the user would be re-directed to login in either case. You might want to consider using sticky sessions.
Has you may know, Web sites hosted under Microsoft Azure Web Sites service are by default configure to timeout after idling 20 minutes (idleTimeout) and the application pool to restart every 29 hours (periodicRestart). This cause the web site to be slow for the first user accessing it.
I would like to know if the new "Always On" setting available on standard mode will prevent both situation from happening.
I found a few articles mentioning the feature, they are all very clear that the idle timeout will be avoided but none of them explicitly talks about the periodic restart:
One of the other useful Web Site features that we are introducing
today is a feature we call “Always On”. When Always On is enabled on
a site, Windows Azure will automatically ping your Web Site regularly
to ensure that the Web Site is always active and in a warm/running
state. This is useful to ensure that a site is always responsive (and
that the app domain or worker process has not paged out due to lack of
external HTTP requests).
http://weblogs.asp.net/scottgu/archive/2014/01/16/windows-azure-staging-publishing-support-for-web-sites-monitoring-improvements-hyper-v-recovery-manager-ga-and-pci-compliance.aspx
Also the Azure Documentation is not very explicit:
Always On - By default, web sites are unloaded if they have been idle
for some period of time. This lets the system conserve resources. You
can enable the Always On setting for a site in Standard mode if the
site needs to be loaded all the time. Because continuous web jobs may
not run reliably if Always On is disabled, you should enable Always On
when you have continuous web jobs running on the site.
http://www.windowsazure.com/en-us/documentation/articles/web-sites-configure/
Yes both of them will be prevented.
The default 29 hours periodicRestart was never on Azure Websites. That feature is an IIS feature that was enforced by WAS and was designed to run on a server level meaning restart all the worker processes on an IIS server. Both these things (WAS and IIS Server) don't apply to Azure Websites as WAS was the process management component of IIS and that was very specific to one box setup. Azure Websites uses a different process management component that doesn't have periodicRestart.
I have created a WCF service which i have hosted in IIS. When I start the service in IIS, the Service do not started until I browse my Service.svc file.
Application pool gets recycled after a specific interval, then when the Service is restarted I again need to go and browse the Service.svc file.
I have set this Service as Default bt it does not work and results the same.
Is there any way to automatic browse my Service.svc file when the Service is started or restarted.
This is a general annoyance with IIS. It launches worker processes to perform website processing which don't (always) start until the website has been requested. The workaround I've used in the past is to hit a page outside of my web application to launch the IIS worker process so it is available when I need it. Be careful though there are some nuances to the app pools that can make this more complicated than it needs to be.
I have a problem with timeouts in IIS. In the web.config the session timeout was set to 60 minutes but after 20 minutes the session ends.
This problem only occurs in IIS7 and not in IIS5.
After some investigation, I discovered it was due to the application pool's timeout. If the App Pool is left 20 minutes without doing anything, IIS ends the session.
If the application is using the defaultAppPool this always happens but if I change the App Pool to the classic .NET App Pool, the timeout does not occur.
Both modes have idle timeout but only in the DefaultAppPool this occurs.
Why is this?
What is the difference between be a Classic .NET AppPool and DefaultAppPool?
What is the difference in the pipeline, between Classic and Integrated?
IIS7 has some major changes to better support WCF and one of the key pieces is the new integrated application pool. This session from PDC talks about some of these challenges from the perspective of making WCF services perform better: http://channel9.msdn.com/pdc2008/TL38/
This page has a good overview of IIS7 architecture: http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/.
I've included some of the key information from this article on the purpose of the two different kinds of app pools below:
Integrated application pool mode
When an application pool is in
Integrated mode, you can take
advantage of the integrated
request-processing architecture of IIS
and ASP.NET. When a worker process in
an application pool receives a
request, the request passes through an
ordered list of events. Each event
calls the necessary native and managed
modules to process portions of the
request and to generate the response.
There are several benefits to running
application pools in Integrated mode.
First the request-processing models of
IIS and ASP.NET are integrated into a
unified process model. This model
eliminates steps that were previously
duplicated in IIS and ASP.NET, such as
authentication. Additionally,
Integrated mode enables the
availability of managed features to
all content types.
Classic application pool mode
When an application pool is in Classic
mode, IIS 7.0 handles requests as in
IIS 6.0 worker process isolation mode.
ASP.NET requests first go through
native processing steps in IIS and are
then routed to Aspnet_isapi.dll for
processing of managed code in the
managed runtime. Finally, the request
is routed back through IIS to send the
response. This separation of the IIS
and ASP.NET request-processing models
results in duplication of some
processing steps, such as
authentication and authorization.
Additionally, managed code features,
such as forms authentication, are only
available to ASP.NET applications or
applications for which you have script
mapped all requests to be handled by
aspnet_isapi.dll. Be sure to test your
existing applications for
compatibility in Integrated mode
before upgrading a production
environment to IIS 7.0 and assigning
applications to application pools in
Integrated mode. You should only add
an application to an application pool
in Classic mode if the application
fails to work in Integrated mode. For
example, your application might rely
on an authentication token passed from
IIS to the managed runtime, and, due
to the new architecture in IIS 7.0,
the process breaks your application.
The classic pool processes the requests in the app pool by using seperate processing pipelinesfor IIS and ISAPI. integrated uses an integrated pipeline, IIS and ASP.NET a(better performance) takes advantage of the improved features of IIS 7.0 using only the one process.
Good practise is to create a new application pool for each application, then configure sepeerately according to application requirements.
Classic mode follows the steps below :
1.The incoming HTTP request is received through the IIS core.
2.The request is processed through ISAPI.
3.The request is processed through ASP.NET.
4.The request passes back through ISAPI.
5.The request passes back through the IIS core where the HTTP response finally is delivered
Integrated mode uses:
1.The incoming HTTP request is received through the IIS core and ASP.NET.
2.The appropriate handler executes the request and delivers the HTTP response
Increase the session timeout in web.config as per
remember increasing this causes the application to consume more resource, eg memory
I think your question has the answer in it. IIS 6 and 7 have a concept of Application Pool timeout, this is different from session timeout.
What is the difference between modes ... already addressed. I'm uncertain about how your questions regarding pipelines and differences in modes relate to your problem - the timeouts.
Some perspective: Idle timeout won't occur on a web site with any traffic. You've probably got a problem that only occurs in a QA site or your dev box. The idle timeout setting exists to save resources on your dev box and $5/month hosting companies with lots of underused web sites (e.g. my blog). You probably do not want idle timeout on a public site.
Session timeout - set in web config, if a user doesn't hit the server, their session times out.
Idle timeout Noone touches the web server at all for 20 minutes, so shut down to save resources. In IIS 6, this is on the performance tab of the app pool - and is easy to disable. In IIS 7, you can set in in application pool advanced settings or in the processModel element. I don't run as much IIS 7 as IIS 6, but it looks like removing the element from web.config, or setting to 0, gets infinite idle timeout.
The DefaultAppPool ignores settings for session timeout in web.config, but ASPNet App Pool will use the settings in web.config.