Recently, some of my IIS application is having no response. I check the event log and found that some
error happened in WAS service which cause some application pool to be stopped.
The following is the error message.
I can see only the process id causing
the problem.
I checked the error and find in one apppool a process is exceeded time limits during shut down.
Is that possible the process cannot shutdown and cause the other apppool to shutdown. My solutions is set the Test_pool application pool timeout to 1440 minutes(24 hour) and set recylcing time at a specific time
of the day to avoid the shutdown failure of process and prevent the auto shutdown of application pool. Is that workable?
A process serving application pool 'CEHL_POOL' exceeded time limits during shut down. The process id was '529004'.
A worker process '504596' serving application pool 'TEST_POOL' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.
A worker process with process id of '794136' serving application pool 'TEST_POOL' was shutdown due to inactivity. Application Pool timeout configuration was set to 20 minutes. A new worker process will be started when needed.
Application pool 'TEST_POOL' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
Application pool 'DefaultAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
The event logs included mutiple errors with different application pool. So please point out which application pool stop responding. The error message "exceeded time limits during shut down" means the application failed to finish all current requests inside the process before application pool shutdown timeout reached. So either threads hang up or locked up.
“being automatically disabled due to a series of failures。。。”is caused by rapid failure protection, so you need to check application events and you should be able to find the crash event.
No matter crash or hang, you need to reproduce the issue and monitor the request status inside worker process monitor. It will show the time taken and current handler. You may need to collect and analyze dump file to trace the root cause.
Besides, in some case, http.sys will cause this issue because it is no longer able to wake up a new appliction pool. You may need to check whether your application pool is able to be waked up after your application stop responding.
Related
I have two Application Pools, Prod_Apps_Pool and Prod_Mobs_Pool. For some reason, the Prod_Apps_Pool will keep stopping, but the Prod_Mobs_Pool will keep running just fine. I do understand that it's the Rapid-Fail Protection that is turning off the pool; what I don't understand is what failing specific process is causing this.
Looking at Event Viewer, I do get a System Error that says "Application pool 'Prod_Apps_Pool' is being automatically disabled due to a series of failures in the process(es) serving that application pool." Prior to this error, I have several warnings about processes serving the pool exceeding time limits during shut down, as well as processes requesting a recycle due to reaching a virtual memory limit.
I do not see anything in the Application Log, nor anything in the W3SVC# logs IIS logs. If I had to guess, I would say that these processes that are exceeding time limits are counting as "failures", the maximum number of failed processes in a given time limit is being hit, and then the Rapid-Fail Response is being triggered stopping the application pool. I would further guess that one of the applications in the pool specifically is causing these issues.
How can I specifically find out which application is causing this to happen? The only thing I have seen suggested so far is to put every single application in the pool into it's own pool, then find out which pool is shutting it down. But aside from the impracticality of separating a pool with dozens of applications into dozens of separate pools, this still doesn't tell me what error is causing all of this.
What's the best approach to narrow down the application and error causing this?
I have a ASP.NET application running on IIS 8. My application sometimes does not respond to request with clients logging a timeout and then IIS starts sending out 503 Unavailable response codes. Each outage seems to last 5 minutes which corresponds to a 5 minute limit interval for Kill w3wp.
I have the App Pool configured for a Kill w3wp limit action with limit percentage of 80%.
While it might seems the pool is getting killed due to high CPU usage, I could not find any records in the event viewer. In fact, it had gone to idle state because of no requests in about 25 minutes.
The crash happened with 3 simple identical requests issued when the pool was idle.It cannot be reproduced manually in any environment.
This is happening about once a week. Since its a critical application, its running on a separate server with no other applications installed.
I have changed the Limit from Kill to throttle but I am not sure its a good idea. Anyways I've got to find a way to reproduce this.
Can the pool fail to exit an idle state?
If there is no traffic, w3wp.exe may go idle aka stop running. But that is not the same as it being truly stopped and it would not cause a 503. It would just start back up on the next request.
A 503 is more likely because your IIS App Pool is crashing or literally being stopped.
I would check Windows Event Viewer to see if says anything around that time frame around w3wp crashing. You can also set IIS to do more detailed logging anytime your w3wp app pool is stopped, started, recycled.
Docs about enabling more app pool logging:
https://technet.microsoft.com/en-us/library/cc753412%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
You could also search various IIS logs for errors:
https://stackify.com/beyond-iis-logs-find-failed-iis-asp-net-requests/
If you set auto recycle option then remove it and make it schedule recycle instead.
It seems as the memory consumption by your application tends to saturation level, IIS being recycled
In IIS7 Application Pool there is a setting Idle-time out default is 20 min,
which says:
Amount of time(in minutes) a worker process will remain idle before it shuts down, A worker process is idle if it is not processing requests and no new requests are received.
My question is, if the worker process shut down because of the time-out time, does the session created by application which is hosted in this worker process get lost?
Yes -- the session data is tied to the app pool worker process, so once the worker gets shut down, the session data is lost.
The default behavior is to store session variables in the memory space of the ASP.NET worker process.
(Of course, this assumes you're using InProc as the session mode. If you're using the database, then it will persist after the worker gets shut down.)
I met an issue in ASP.Net. In any Web App config Web.config file there is a section called httpRuntime, and it has an attriube: shutdownTimeout. According to MSDN documentation, this attr specify how long the idle time of the worker process is allowed before ASP.Net runtime to terminate the worker process. On another side, under IIS's ApplicationPool's -> Default AppPool -> properties -> performance tab, there is a setting: "shutdown worker process after being idle for (20) minutes".
I guess that under IIS, this setting is for all worker process which is used to handle incoming request not only the process where a specific ASP.Net runtime resides. And if Web.Config's shutdownTimeout has not taken effect yet, the IIS's setting would then do its work.
However from my observation, although the httpRuntime's shutdownTimeout default value is 90 seconds, my web application was always shut down after idle for 20 minutes. It seems the IIS setting take priority for this aspect.
It is much appreciated if somebody could clarify on this: what is wrong with my guess.
I did some digging and found out the answer:
the attriubte shutdownTimeout controls how long the ASP.Net runtime will shut down the worker process before it gracefully exits by itself if it is asked to terminate by the ASP.Net runtime.
Is this right, any opinion is greatly appreciated.
https://msdn.microsoft.com/en-us/library/e1f13641(v=vs.100).aspx
Specifies the number of minutes that are allowed for the worker process to shut down. When the time-out expires, ASP.NET shuts down the worker process.
The default is 90.
So basically, the worker process has X minutes to shut down the worker process. If it reaches X it is killed.
In an ASP.NET website we are storing sessions in SQL Server. All is working fine except that sessions frequently recycle. I've a timeout period set to 30 minutes but some times it recycles within a few minutes. We've a dedicated server, and website running under a 'classic' application pool. I've searched a lot on this problem, but didn't find a satisfactory answer. Any help will be greatly appreciated.
Note: mostly it happens on a page where there is lots of use of viewstate, I'm curious that is there a link of viewstate with session recycling?
We've experienced this problem when we either have a web farm (more than one web server servicing clients) or a web garden (more than one worker process in an application pool).
If you have a web farm, then you need to ensure that all web servers have the same machine key and that all instances have the exact same application path.
If you have a web garden, try dropping the maximum worker processes back to 1 to see if that resolves the issue.
While you are checking the IIS settings, you should probably also ensure that the application pool is not recycling regularly. This can be due any of the following specified in the app pool:
1) Private Memory Limit (the app pool is reset if the maximum amount of memory has been exceeded)
2) Regular Time Interval recycling (the app pool is automatically recycled after a specified number of minutes, defaulting to 1740, and/or at specific times).
3) Idle Time-out (the number of minutes of inactivity that can elapse before the application pool is automatically shutdown).
You should also check the event logs for reports of the application pool crashing or otherwise being recycled.
Update:
An additional thought:
If you have an application, such as anti-virus or backup software, that monitors your application's bin directory and modifies or changes attributes (such as the backup flag or timestamp) of files in that directory OR your web.config file, this will cause application recycling as well.