M
Mike Schilling
We've recently started porting our web service application to IIS 6.0. To
minimize the behavior changes, we've put it into its own application pool,
which never creates replicates. Also, since the application maintains
intenral state, we don't want the pool process recycled, so we've turned off
automatic recylcing and pinging for this pool.
At low load levels, it all works fine. But when we raise the load, before
too long these things happen:
1. The application stops responding. Further request to comminucate with it
hang.
2. The CPU utilization on the machine goes to 0.
3. The following appears in the application log:
Source: W3SVC-WP
Category: None
Type: Warning
Event ID: 2262
ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll'
reported itself as unhealthy for the following reason: 'Deadlock
detected'.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
There is no description of this error at that location.
I don't think there's any actual deadlock, since the same application works
fine in IIS 5.0. (All this version of it does is route messages between web
services on different machines.) Rather, I suspect that at high load,
latency or request queue sizes get large enough that ASP.NET considers the
application to be broken.
A few questions, then:
1. What parameters is ASP.NET using to decide that the application is
unhealthy? In IIS 5.0, I'd look into things like
responseRestartDeadlockInterval and responseDeadlockInterval, but the IIS
machine.config says:
When ASP.NET is running under IIS 6 in native mode, the IIS 6 process
model is
used and settings in this section are ignored. Please use the IIS
administrative
UI to configure things like process identity and cycling for the IIS
worker process for the desired application
I can't find anything in the IIS administrative UI that seems related,
though.
2. The behavior seems odd to me. In IIS 5.0, when the worker process seemed
unhealthy, ASP.NET killed it and started a new one. Why, in this case, is
the process left in an idle state, and why do requests to it hang instead of
failing?
Any insights greatly appreciated.
minimize the behavior changes, we've put it into its own application pool,
which never creates replicates. Also, since the application maintains
intenral state, we don't want the pool process recycled, so we've turned off
automatic recylcing and pinging for this pool.
At low load levels, it all works fine. But when we raise the load, before
too long these things happen:
1. The application stops responding. Further request to comminucate with it
hang.
2. The CPU utilization on the machine goes to 0.
3. The following appears in the application log:
Source: W3SVC-WP
Category: None
Type: Warning
Event ID: 2262
ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll'
reported itself as unhealthy for the following reason: 'Deadlock
detected'.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
There is no description of this error at that location.
I don't think there's any actual deadlock, since the same application works
fine in IIS 5.0. (All this version of it does is route messages between web
services on different machines.) Rather, I suspect that at high load,
latency or request queue sizes get large enough that ASP.NET considers the
application to be broken.
A few questions, then:
1. What parameters is ASP.NET using to decide that the application is
unhealthy? In IIS 5.0, I'd look into things like
responseRestartDeadlockInterval and responseDeadlockInterval, but the IIS
machine.config says:
When ASP.NET is running under IIS 6 in native mode, the IIS 6 process
model is
used and settings in this section are ignored. Please use the IIS
administrative
UI to configure things like process identity and cycling for the IIS
worker process for the desired application
I can't find anything in the IIS administrative UI that seems related,
though.
2. The behavior seems odd to me. In IIS 5.0, when the worker process seemed
unhealthy, ASP.NET killed it and started a new one. Why, in this case, is
the process left in an idle state, and why do requests to it hang instead of
failing?
Any insights greatly appreciated.