D
Dominic
Hi all,
We've just migrated to IIS 6.0 / Windows Server 2003. We are now
experiencing some stability problem what we did not experience in IIS
5.0 / Windows 2000 Server. Our ASP.NET application is running in a
web-farm environment of multiple web servers. We have been using
"Performance Monitor" to monitor the "Requests in Application Queue"
counter of "ASP.NET Apps v.1.1.4322" object. We have found the
following pattern.
In normal situation (when the application is running very stable),
this counter "Requests in Application Queue" of all web servers
remains zero. However, whenever the value of this counter of a certain
web server (in the web farm) jumps to a value bigger than zero (say
70), the performance of our application at that web server becomes
very slow. This problem usually persists for a minute or two.
Afterwards, the following application event log and system event log
will then appear.
Event Type: Warning
Event Source: W3SVC-WP
Event Category: None
Event ID: 2262
Date: 12/13/2004
Time: 5:16:11 PM
User: N/A
Computer: Server-Xyz
Description:
ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll'
reported itself as unhealthy for the following reason: 'Deadlock
detected'.
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1013
Date: 12/13/2004
Time: 5:18:02 PM
User: N/A
Computer: Server-Xyz
Description:
A process serving application pool 'AppPoolXyz' exceeded time limits
during shut down. The process id was '3256'.
Finally, our ASP.NET application will then restart by itself. The
"Requests in Application Queue" will become zero, and the performance
becomes normal again. Later, this problem may happen to another server
in our web farm.
BTW, since each web server is dual-processor machine, the number of
worker processes (web-garden) in IIS 6 manager setting is set to 2.
We have already turned off the "Recycle Worker Process" option. We
have also applied .NET framework 1.1 SP1.
My question is why this occurs and how we can solve the problem. Any
insight is greatly appreciated.
Dominic
We've just migrated to IIS 6.0 / Windows Server 2003. We are now
experiencing some stability problem what we did not experience in IIS
5.0 / Windows 2000 Server. Our ASP.NET application is running in a
web-farm environment of multiple web servers. We have been using
"Performance Monitor" to monitor the "Requests in Application Queue"
counter of "ASP.NET Apps v.1.1.4322" object. We have found the
following pattern.
In normal situation (when the application is running very stable),
this counter "Requests in Application Queue" of all web servers
remains zero. However, whenever the value of this counter of a certain
web server (in the web farm) jumps to a value bigger than zero (say
70), the performance of our application at that web server becomes
very slow. This problem usually persists for a minute or two.
Afterwards, the following application event log and system event log
will then appear.
Event Type: Warning
Event Source: W3SVC-WP
Event Category: None
Event ID: 2262
Date: 12/13/2004
Time: 5:16:11 PM
User: N/A
Computer: Server-Xyz
Description:
ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll'
reported itself as unhealthy for the following reason: 'Deadlock
detected'.
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1013
Date: 12/13/2004
Time: 5:18:02 PM
User: N/A
Computer: Server-Xyz
Description:
A process serving application pool 'AppPoolXyz' exceeded time limits
during shut down. The process id was '3256'.
Finally, our ASP.NET application will then restart by itself. The
"Requests in Application Queue" will become zero, and the performance
becomes normal again. Later, this problem may happen to another server
in our web farm.
BTW, since each web server is dual-processor machine, the number of
worker processes (web-garden) in IIS 6 manager setting is set to 2.
We have already turned off the "Recycle Worker Process" option. We
have also applied .NET framework 1.1 SP1.
My question is why this occurs and how we can solve the problem. Any
insight is greatly appreciated.
Dominic