![IIS 6.0 中的请求执行泄漏直至服务器繁忙](https://linux22.com/image/573304/IIS%206.0%20%E4%B8%AD%E7%9A%84%E8%AF%B7%E6%B1%82%E6%89%A7%E8%A1%8C%E6%B3%84%E6%BC%8F%E7%9B%B4%E8%87%B3%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%B9%81%E5%BF%99.png)
我有一个在 IIS 6 上运行的应用程序,它受到数百个远程客户端的攻击,这些客户端发出各种请求,有些请求长时间运行,有些则不是。
在一些部署中,特别是目前的一次部署中,ASP .NET 应用程序 - 请求执行计数器不断攀升,直到达到限制(5000),然后服务器停止接受请求。
在诊断问题时,这里有一些非常有趣的事实:
w3p 进程和系统进程的线程数都较低(低于 100)
整个系统的 CPU 较低
netstat -a 中列出的 TCP 连接总数(任何状态下)约为 600,这是预料之中的,因为我们有大约 600 个远程客户端。
那么,为什么当实际上没有发生任何事情并且一切似乎都正常启动和终止时,IIS 中执行的请求数会是 5000?
编辑
我想补充一点,这些是使用 IHttpAsyncHandler 模式的异步调用。我相信这些没有超时。
答案1
“在某些部署上”——这是什么意思?
简短的回答:因为您的工作线程被绑定并挂起,并且没有超时。
如果是 ASP.Net,则线程零售模式120 秒后应超时。
因为它们不是,所以非常出现严重错误,或者您正在以调试模式运行,即在<compilation debug="true">
某处(机器或 web.config)的配置文件中进行设置。
此项绝不应在生产网络服务器上进行设置。
如果不是这种情况,请获取 DebugDiag 1.2,并使用它来评估应用程序在泄漏线程时的内存转储。它应该能够向您显示泄漏的执行请求的线程堆栈,希望这能帮助您理解和解决问题。
答案2
您陈述:
执行各种请求,有些是长期运行的,有些则不是。
长时间运行的请求最终会毁掉你的服务器。如果你有大量这样的请求,那么最终会导致线程池耗尽,并达到允许的最大请求数。
如果这些长时间运行的请求是 I/O 密集型的(但不是 CPU 密集型的),例如调用其他 Web 服务或等待 SQL 操作完成,则考虑将这些页面转换为异步页面:
如果您使用 ASP.NET MVC,那么您可以做同样的事情: