I ran into an issue with an IIS web app shutting down an idle worker process! The next request would then have to re-initialize the application, leading to delays.
I disabled the IIS shutdown of idle worker processes on the application pool to resolve this. Are there any issues associated with turning this off? If the process is leaking memory, I imagine it is nice to recycle the process every now and then.
Are there any other benefits to having this process shutdown?
I'm assuming that you're referring to IIS 6.
Instead of disabling shutdown altogether, maybe you can just increase the amount of time it waits before killing the process. The server is essentially conserving resources - if your server can stand the resource allocation for a process that mostly sits around doing nothing, then there isn't any harm in letting it be.
As you mentioned, setting the auto-recycling of the process on a memory limit would be a good idea, if the possibility of a memory leak is there.
Related
I stopped the World Wide Web Publishing Service - normally this service won't stop until all of the w3wp.exe processes shut down. But I am now seeing a strange behavior where the service actually stops quickly -- but the w3wp.exe is still there, and those processes end after a number of seconds (10-15 seconds?) Did something change in the behavior of IIS?
The default ShutdownTimeLimit value is 90 seconds. application pool needs time to fully shut down, as any requests currently processing when the shutdown is initiated and needs to be given a certain amount of time to complete.
if it takes too long time to shut down then you could troubleshoot the application pool by capturing a memory dump of the w3wp.exe process in which the application pool is running, when the shutdown problem is occurring.
For more information on capturing memory dumps of IIS processes, see Debug Diagnostics Tool v1.2 is now available.
I have a website in IIS 8.5.9600.16384, we communicate with thousands of mobile devices through cyclic synchronisation and through SignalR 2.3.0.
This morning we had an application pool reset during working hours, which caused the SignalR to call "OnReconnect" of all our mobile devices at the same time.
I though that IIS started new processes first and then killed the old, not having downtime.
Can somebody tell me exactly what happens when IIS recycles it's application pool on the SignalR side? And in which cases can there be a connection downtime? (ex : if the server is busy?)
Edited : The application pool was recycled by IIS because of the "time limit". The IT team will change this setting so that the application pools reset every day at night time when it will have a lower impact on our applications.
A worker process with process id of '8720' serving application pool 'DefaultAppPool' has requested a recycle because the worker process reached its allowed processing time limit.
Also confirmed that disallowOverlappingRotation is not set to True. Any hint would help.
A few years later, I'm still getting some problems with the application pool recycle and SignalR. We are occasionally seeing thousands of re-connections of SignalR while the application pool recycle occurs, opening more than 60k TCPIP ports and causing a crash in IIS.
We managed to have it run "okay" for quite some time but it still crashes. Any hint would help. thanks
I'd first identify how IIS was reset. If you experienced a crash or performed an IISReset, the processes would be down before a new one stood back up. If on the other hand you configured AppPool recycling, then the overlapping processes should occur as you mention. I would check the System Event Log for recycling messages. Note that not all recycle reasons are logged by default.
You may also check to make sure disallowOverlappingRotation is not set to True.
Specifies whether the WWW Service should start another worker process to replace the existing worker process while that process is shutting down. The value of this property should be set to true if the worker process loads any application code that does not support multiple worker processes.
https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/applicationpools/add/recycling/
According to nodetime, my memory leak is persisting even through node application restarts. Check out the following "OS - Free Memory" graph; notice how the memory decreases steadily (despite the node app restarting dozens and dozens of times) until I restart the whole server:
How is this possible? Am I fundamentally misunderstanding something? I don't understand how a memory leak in one process could survive and continue to affect the OS...
Machine Info:
Amazon EC2 (m1.large) running CentOS
A memory leak in one process (that is actually killed) can't do this.
Are you using 3rd party systems to provided shared state? For example, a database, or something like redis for sessions? In that case, restarting your node process will just lead to reconnecting to the same shared state and continuing whatever leak was started initially.
can someone explain for me this sentence from msdn ?
Idle time-out can be helpful in the following situations:
The server has a heavy processing load.
is the idle timeout for the w3wp.exe process or each user that's connected to the website has a nested process inside the w3wp and this is the idle time for this nested process? if it's the idle process for w3wp as a whole , then what does msdn sentence mean??
It prevents a application pool worker process from hanging around when no users are hitting the web pages hosted by the worker process. When the users stop hitting the web site for a while, IIS stops the process.
This can be annoying if you have an expensive setup/teardown process for the application, such as populating a cache.
The idle timeout is per application pool. You can observe the running pools as well as in IIS in VS by Tools > Attach to Process then I click the Process column header to bring any running w3wp.exe's to the top.
You can set the timeout for each app pool in IIS7+ in Advanced Settings... Process Model section.
I try to use the winDBG (adplus) to dump the w3wp process.
When I run this command adplus.vbs -hang -quiet -p ****, I found it create a folder with a big size file, and the size was growing. Then suddenly, the big size file disappeared and the process re-start again. Does anyone know about it?
Best Regards,
Yongwei,
Colin is right; in effect, you're racing against IIS as it is recylcing the application pool. As you're snapping your process snapshot, you're either hitting a memory-threshold for recycling, or health checks are perceiving the process to be hung and instituting a recycle (possibly due to ADPlus locking the process)
Here's how I would modify your application pool characteristics prior to attempting your next capture. You only need these changes in effect for as long as it takes to capture your dump:
Turn off memory-based recycling limits (physical and virtual)
Turn off the idle timeout limit (if it's on)
Disable both Pinging and Rapid Fail Protection
In effect: you need to turn off all of the features that try to keep your app pools running well. Capturing a memory snapshot takes time (as you know).
I would also recommend checking out ProcDump (http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx) from the SysInternals guys. It was just released last month, and it makes process memory captures a bit easier. An article on using it to capture the W3WP is here: http://blogs.msdn.com/webtopics/archive/2009/08/08/using-procdump-exe-to-monitor-w3wp-exe-for-cpu-spikes.aspx
I hope this helps!
I can only imagine the memory usage of the w3wp process got to much which triggered an app pool recycle, which means restarting w3wp.