Help and Support

文章编号: 821268 - 最后修改: 2009年7月7日 - 修订: 9.0

争用、 性能不佳的情况和死锁时从 ASP.NET 应用程序的 Web 服务请求

本页

展开全部 | 关闭全部

症状

要从一个 ASP.NET 调用 XML Web 服务时应用争用,性能不佳的情况和死锁可能会遇到。 客户端可能会报告请求停止响应 (或"挂起"),或要花很长时间才能执行。 如果怀疑死锁,可能就是回收工作进程。 在应用程序事件日志中,您可能会收到以下消息。
  • 如果您正在使用 Microsoft Internet Information Services (IIS) 5.0,您在应用程序事件日志中收到以下消息:

       Event Type:     Error
       Event Source:   ASP.NET 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_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
          It 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:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
          unhealthy for the following reason: 'Deadlock detected'.

  • 如果您使用 IIS 6.0,可以在系统事件日志中收到以下消息:

       Event Type:     Warning
       Event Source:   W3SVC
       Event Category: 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 down.
          The process id was '<xxxx>'.

还可能收到下面的异常错误消息时调用该 HttpWebRequest.GetResponse 方法:
“ System.InvalidOperationException: ThreadPool 对象来完成该操作中没有有足够的自由线程 ”
还可能在浏览器中收到下面的异常错误消息:
“ HttpException (0x80004005): 请求超时 ”
请注意 本文还适用于直接进行 HttpWebRequest 请求的应用程序中。

原因

因为 ASP.NET 限制的工作线程和完成端口线程调用可用于执行请求的数量,可能会出现此问题。

通常,Web 服务调用使用执行该代码将请求发送的一个工作线程完成端口线程从 Web 服务中接收回调。 但是,如果请求重定向或要求身份验证,调用可能要使用多达两个工作和完成端口的两个线程。 因此,您可以同时发生的多个 Web 服务调用时耗尽托管的 ThreadPool。

渚嬪的方式  假设 ThreadPool 被限制为 10 的工作线程,所有的 10 个工作线程正在执行正在等待执行回调的代码。 因为排队到 ThreadPool 的任何工作项被阻止,直到线程可用,可以永远不会执行回调。

争用的另一个潜在的源是 maxconnection 参数 System.Net 命名空间用来限制连接数。 通常,此限制正常工作。 但是,如果很多应用程序试图同时请求多对单个 IP 地址,线程可能必须等待可用连接。

解决方案

若要解决这些问题,您可以以最适合您的具体情况 Machine.config 文件中调整以下参数:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
成功地解决这些问题,执行下列操作:
  • 限制可以为每个 CPU 的大约 12 同时执行的 ASP.NET 请求的数量。
  • 允许 Web 服务回调自由地在 ThreadPool 中使用线程。
  • 选择用于 maxconnections 参数的合适值。 基于所选内容的 IP 地址和使用的应用程序域的数目。
请注意 若要限制的每个 CPU 的 12 ASP.NET 请求的数量建议有点任意。 但是,此限制了事实证明适用于大多数应用程序。

maxWorkerThreads maxIoThreads

ASP.NET 使用以下两个配置设置限制的辅助线程和使用的完成线程的最大数量:
<processModel maxWorkerThreads="20" maxIoThreads="20">
maxWorkerThreads 参数和 maxIoThreads 参数隐式相乘的 CPU 数。 渚嬪的方式  如果两个处理器,最大的工作线程为下列:
2 * maxWorkerThreads

minFreeThreads minLocalRequestFreeThreads

ASP.NET 还包含下列配置设置来确定多少工作线程和完成端口线程必须可用于启动请求远程或本地请求:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
如果没有足够的线程可用,请求排队直到足够线程自由地发出请求。 因此,ASP.NET 不能执行多个以下数量的请求在同一时间:
( maxWorkerThreads * number of CPUs) 的 minFreeThreads
请注意 minFreeThreads 参数和 minLocalRequestFreeThreads 参数不隐式相乘的 CPU 数。

minWorkerThreads

ASP.NET 1.0 Service Pack 3 和 ASP.NET 1.1,ASP.NET 还包含以下配置设置来确定多少工作线程可能会获得可立即向远程请求提供服务。
<processModel minWorkerThreads="1">
受此设置的线程可以创建的速率很多更快地比从 CLR 的默认"线程优化"功能创建的工作线程。 此设置使 ASP.NET 能够可能突然填充到后端服务器突然突发的请求从在客户端或类似的内容将导致在队列中的一个突然上升的请求数的上一个 slow-down 由于 ASP.NET 请求队列的服务请求。 为 minWorkerThreads 参数默认值为 1。 我们建议您将该参数值的 minWorkerThreads 设置为下面的值。
minWorkerThreads = maxWorkerThreads / 2
通过默认, minWorkerThreads 参数不存在或者 Web.config 文件或 Machine.config 文件中。 此设置隐式乘以的 CPU 数。

maxconnection

maxconnection 参数确定多少可以无法连接到特定的 IP 地址。 该参数如下所示:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="65.53.32.230" maxconnection="12">
</connectionManagement>
所有在进程级别的该设置本文前面的参数。 但是, maxconnection 参数的设置将应用于 AppDomain 级别。 通过默认,因为此设置适用于在 AppDomain 级别可以创建两个连接的最大到特定的 IP 地址从每个 AppDomain 在过程中。

executionTimeout

ASP.NET 使用以下配置设置,来限制请求执行时间:
<httpRuntime executionTimeout="90"/>
也可以通过使用 Server.ScriptTimeout 属性中设置此限制。

请注意 如果您增加 executionTimeout 参数的值,您可能还要修改 processModel responseDeadlockInterval 参数的设置。

建议

建议在本部分中使用的设置可能不适用于所有应用程序。 但是,以下附加信息可以帮助您进行相应的调整。

如果您制作一个 Web 服务调用单个 IP 地址从每个 ASPX 页面 Microsoft 建议您使用以下配置设置:
  • maxWorkerThreads 参数和 maxIoThreads 参数的值设置为 100
  • 设置 maxconnection 参数的值 12 * N (其中 N 是您的 CPU 数量)。
  • 设置 minFreeThreads 参数的值 88 * N,并使用 minLocalRequestFreeThreads 参数 76 * N
  • minWorkerThreads 的值设置为 50 。 请记住 minWorkerThreads 不在默认情况下,配置文件中。 您必须将其添加。
这些建议的某些涉及涉及在服务器上的 CPU 数的简单的公式。 变量,该值代表公式中的 CPU 数量是 N。 这些设置,如果您具有超线程已启用,则必须使用逻辑的 CPU 数目而不是物理 CPU 数量。 渚嬪的方式  如果您有一个四处理器服务器启用超线程,则公式中的 N 值将 8 而不是 4

请注意 当您使用此配置时,您可以执行 12 ASP.NET 请求,每个 CPU 的最大同时因为 100-88 = 12 。 因此,至少 88 * N 工作线程和 88 * N 完成端口线程不可用的其他使用 (例如,Web 服务的回调)。

渚嬪的方式 ,您有了一个具有四个处理器和启用超线程的服务器。 基于这些公式,您可以使用下面的值在本文中提到的配置设置。
<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50">
<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"> 
<connectionManagement>
	<add address="[ProvideIPHere]" maxconnection="96"/>
</connectionManagement>

此外,当您使用此配置,12 连接有每个 CPU 每个为每个 AppDomain 的 IP 地址。 因此,在下面的情况下很少的争用时发生请求正在等待连接,和不耗尽 ThreadPool:
  • 在网站承载只能有一个应用程序 (AppDomain)。
  • 每个 ASPX 页面请求使一个 Web 服务请求。
  • 所有请求都都相同的 IP 地址。
但是,当您使用此配置,涉及下列选项之一的方案将可能使用太多的连接:
  • 请求将多个 IP 地址。
  • 请求是重定向 (302 状态代码)。
  • 请求需要身份验证。
  • 请求是从多个应用程序域。
在这些情况下,最好用于 maxconnection 参数和更高的值 minFreeThreads 参数和值 minLocalRequestFreeThreads 参数的较低的值。

状态

此行为是设计使然。

更多信息

如果您遇到性能不佳的原因和 ASP.NET 的 IIS 7.0 上争用,请参阅下面的 Microsoft 博客:
在 IIS 7.0 和 6.0 ASP.NET 线程使用
http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx (http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx)

Microsoft IIS 支持小组网络日志:
http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx (http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx)

参考

更多的信息请访问下面的 Microsoft 开发人员网络 (MSDN) 网站:
http://msdn2.microsoft.com/en-us/library/ms998549.aspx (http://msdn2.microsoft.com/en-us/library/ms998549.aspx)

这篇文章中的信息适用于:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
关键字:?
kbmt kbprb KB821268 KbMtzh
机器翻译机器翻译
注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版: 821268? (http://support.microsoft.com/kb/821268/en-us/ )
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性,不作任何声明。 所有该等文件及有关图形均"依样"提供,而不带任何性质的保证。Microsoft和/或其各供应商特此声明,对所有与该等信息有关的保证和条件不负任何责任,该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下,在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中,Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。

文章翻译

 

Related Support Centers