2024年3月27日发(作者：)
IIS服务请求时的死锁、挂起解决方案
IIS服务请求时的死锁、挂起解决方案2010-05-19 10：50症状
使从调用XML Web services时应用您可能会遇到争用、性能下降
和死锁。客户端可能会报告请求停止响应(或"挂起")或需要执.使从调
用XML Web services时应用您可能会遇到争用、性能下降和死锁。客户端可能
会报告请求停止响应(或"挂起")或需要执行一个很长时间。如果怀疑死锁，工
作进程可能回收。应用程序事件日志中，可能会收到以下消息。如果要使用
Microsoft Internet Information Services(IIS)5.0，应用程序事件日志中收
到以下消息：
Event Type：Error Event Source： 1.0.3705.0 Event Category：
None Event ID：1003 Date：5/4/2003 Time：6：18：23 PM User：N/A
Computer：ComputerName Description：aspnet_(PID：xxx)was
recycled because it was suspected to be in adeadlocked did
not send any responses for pending requests in the last 180 seconds.
如果您使用IIS 6.0在应用程序事件日志中收到以下消息：
Event Type：Warning Event Source：W3SVC-WP Event Category：None
Event ID：2262 Date：5/4/2003 Time：1：02：33 PM User：N/A Computer：
ComputerName Description：ISAPI'C：
meworkv.1.1.4322aspnet_'reported
itself as unhealthy for the following reason：'Deadlock detected'.
如果您使用IIS 6.0在系统事件日志中收到以下消息：
Event Type：Warning Event Source：W3SVC Event Categor y：None
Event ID：1013 Date：5/4/2003 Time：1：03：47 PM User：N/A Computer：
ComputerName Description：A process serving application
pool'DefaultAppPool'exceeded time limits during shut process
id was'xxxx'.
在进行调用ponse方法时，您可能还会收到以下异
常错误信息：dOperationException：ThreadPool对象来完成该
操作中未有足够的自由线程"在浏览器中，您可能还会收到以下异常错误信息：
HttpException(0x 80004005)：请求超时"请注意本文还适用于直接发出
HttpWebRequest请求的应用程序中。
原因
限制的工作线程和调用可用于执行请求的完成端口线程数可能会
发生此问题。通常，调用Web服务使用一个工作线程执行发送请求的代码和从
Web服务.限制的工作线程和调用可用于执行请求的完成端口线程数可
能会发生此问题。
通常，调用Web服务使用一个工作线程执行发送请求的代码和从Web服务
接收回调的一个完成端口线程。但是，如果请求被重定向，或要求身份验证，
调用将可以使用多达两个工作和两个完成端口线程。因此，多个Web服务调用
发生在同一时间时可以耗尽托管的ThreadPool。
是例如假设ThreadPool是限制为10的工作线程所有10个工作线程当前执
行正在等待回调执行的代码。回调可以永远不会执行，因为要排队发送至
ThreadPool的任何工作项被阻止，直到线程可用。
另一个潜在的源的争用是命名空间用来限制连接数不超过
maxconnection参数。通常情况下，此限制正常工作。但是，如果许多应用程
序尝试多请求对单个IP地址在同一时间，线程可以等待可用的连接。
解决方案
要解决这些问题，您可以以最适合您的具体情况在文件中
调整以下参数：maxWorkerThreads minWorkerThrea.要解决这些问题，您可以
以最适合您的具体情况在文件中调整以下参数：
maxWorkerThreads minWorkerThreads maxIoThreads minFreeThreads
minLocalRequestFreeThreads maxconnection executionTimeout要成功地解
决这些问题，请执行下列操作：限制在同一时间为每个CPU的大约12可以执行
的请求的数量。允许为自由地在ThreadPool中使用线程的Web服务回
调。选择为maxconnections参数的适当值。您的选择根据IP地址和使用的
AppDomain的数目。请注意要限制对每个CPU的12的请求的数量建议
有点任意。但是，此限制已证明和用于大多数应用程序。
maxWorkerThreads和maxIoThreads 使用限制工作线程和使用的
完成线程的最大数量的下列的两个配置设置：processModel
maxWorkerThreads="20"maxIoThreads="20"
maxWorkerThreads参数和maxIoThreads参数隐式相乘CPU数。是例如如
果两个处理器最大的工作线程数是：2*maxWorkerThreads minFreeThreads和
minLocalRequestFreeThreads 还包含在下面的配置设置，用于确定多
少工作线程和完成端口线程必须可用于启动远程请求或本地的请求：
httpRuntime minFreeThreads="8"minLocalRequestFreeThreads="8"
如果没有足够的线程可用，请求被排队，直到足够的线程都能够发出请求。
因此，不会执行多个下列数量的请求在同一时间：
(maxWorkerThreads*number of CPUs)的minFreeThreads请注意
minFreeThreads参数和minLocalRequestFreeThreads参数不隐式相乘CPU数。
minWorkerThreads 1.0 Service Pack 3和 1.1，
还包含以下配置设置，确定多少工作线程可能可用立即向远程请求提
供服务。processModel minWorkerThreads="1"
受此设置的线程可以创建速度比从CLR的默认"线程优化"功能创建的工作
线程更快得多。此设置可能会突然被填充后端服务器的队列中导致请求数的突
然上升的请求从客户端结束，或类似的突然爆发的slow-down由于在
请求队列的服务请求启用。minWorkerThreads参数，默认值为1。我
们建议您将minWorkerThreads参数的值设置为以下值。
minWorkerThreads=maxWorkerThreads/2
默认，minWorkerThreads参数不是在文件或
文件中存在。此设置隐式乘以CPU数。
maxconnection在maxconnection参数确定多少可以无法连接到特定的IP
地址。参数如下：connectionManagement add
address="*"maxconnection="2"add
address="65.53.32.230"maxconnection="12"/connectionManagement
所有在进程级别的讨论上文中的参数将设置。但是，该maxconnection参
数设置将应用于AppDomain级别。默认，因为此设置适用于该AppDomain级别
可以创建最多两个连接到特定的IP地址从每个AppDomain过程中。
executionTimeout 使用下面的配置设置限制请求执行时间：
httpRuntime executionTimeout="90"/
还可以通过使用TimeOut属性设置此限制。
请注意如果您增加executionTimeout参数的值，还可能必须修改
processModel responseDeadlockInterval参数设置。
建议
建议使用此部分中的设置可能无法对所有应用程序。但是，以下附加信息
可以帮助您进行相应调整。
如果您是一个Web服务调用，到一个单一的IP地址从每个ASPX页，
Microsoft将建议您使用以下配置设置：设置为100的maxWorkerThreads参数
和maxIoThreads参数值。设置maxconnection参数的值12*N(其中，N是必须
的CPU数)。设置minFreeThreads参数的值88*N，
minLocalRequestFreeThreads参数76*N。将minWorkerThreads的值设置为50。
请记住，minWorkerThreads不在默认情况下在配置文件。必须添加它。这些建
议的一些包括涉及在服务器上的CPU数的简单公式。该变量类型的代表公式中
的CPU数为N。这些设置，如果您有超线程启用，必须使用逻辑的CPU数而不
的物理CPU的数字。是例如如果四处理器服务器具有启用超线程，则公式中的
N值将为8，而不是4。
请注意当您使用此配置时，您可以执行每个CPU的12个请求最多
同时因为100 88=12。因此，至少88*N工作线程和88*的其他使用(例如为Web
服务回调)N完成端口线程可用。
是例如，您有一个服务器，而且四个的处理器并启用超线程。根据这些公
式，您将使用下列值这篇文章中提到的配置设置。processModel
maxWorkerThreads="100"maxIoThreads="100"minWorkerThreads="50"httpRunt
ime
minFreeThreads="704"minLocalRequestFreeThreads="608"connectionManagem
ent add
address="[ProvideIPHere]"maxconnection="96"//connectionManagement
此外时使用此配置，12连接可用每个CPU每个每个AppDomain的IP地址。
因此，在下面的情形中很少的争用请求正在等待连接，并ThreadPool不用完时
发生：网站承载只有一个的应用程序(AppDomain)。ASPX页的每个请求将一个
Web服务请求。所有请求都是相同的IP地址。但是，使用此配置时,涉及到下
列项之一的方案将可能使用连接太多：请求是多个IP地址。请求是重定向(302
状态代码)。请求要求身份验证。从多个AppDomain发出请求。在这些情况下，
很好用于maxconnection参数和/minFreeThreads参数和
minLocalRequestFreeThreads参数的更高值的较低的值。
这种现象是设计使然。这种现象是设计使然。
参考
有关详细信息，请访问下面的Microsoft Developer Network(MSDN)网站：
有关详细信息，请访问下面的Microsoft Developer Network(MSDN)网站：(这
篇文章中的信息适用于： Framework 2.0 Microsoft
1.1 Microsoft 1.0回到顶端关键字：kbmt kbprb KB 821268 KbMtzh
发布评论