ASP.NET Requests Queued causes website to crumble. SQL backend, IIS6
我继承了一个需要帮助的稍微复杂的系统(和问题)。
我的网络服务器具有以下规格:
-
硬件:
- Server 2003 32位
- IIS 6
- 8核(16 w /超线程)
- 12GB RAM
- ASP.NET网站
- 3个应用程序池,因此3个w3wp.exe实例正在运行。
该系统可服务大量人员,并且在工作时间内带宽相当稳定,达到?68,000kbit / s
有些时候系统"崩溃"-网站变得非常缓慢,产生了大量电话。通常情况下,速度会降低60秒,但长度却相差很大。有时只有几秒钟,有时只有3分钟或更长时间。
我将我的应用程序池设置为回收约600mb的已消耗内存。那不是确切的,但是他们成功地回收了自己。有时我会手动回收"主"池以清除我正在描述的问题。
这是我知道事情进展缓慢时正在发生的事情。
- 网络带宽会大幅下降。
- 在ASP.NET性能计数器中排队的请求上升。
-
与请求排队的页面上升等待时间一起增加。 (我使用一个简单的ASP页面来进行SQL调用,并只说"系统处于活动状态"-监视此页面的延迟)。
-
总体CPU使用率增加。
- w3wp.exe的整体内存消耗增加。
在我的脑海中,这就是我所想象的正在发生的事情。
有人要求系统生成报告或数据组。这将启动一个消耗大量线程(即所有可用线程)的进程,这将导致对系统的所有其他请求在ASP.NET que池中等待,这实际上会杀死该站点。活动不足会导致网络流量下降。
我已经阅读了许多有关线程队列,线程池等的文章。这是一个很好的示例:http://williablog.net/williablog/post/2008/12/02/Increase-ASPNET-Scalability-Instantly.aspx并提供了我认为可以帮助我解决问题的线索...但是我不我使用的asp.net版本的" Machine.config"文件未指定文章中列出的任何线程值,因此对于我们认为不正确的所有情况,我们都是默认设置。
如果你是我;接下来您要做什么?您认为问题出在哪里?
edit:这是一个屏幕截图。问题发生时应该很明显。
http://i.imgur.com/5BJlq.png
编辑:
我想为我们的设置更改这些值。首先要问几个问题:
1)进行更改后,需要重新启动什么才能使其生效?
2)这些设置如何查找具有8个物理核心的系统?
1 2 3 4 5 | maxconnection = 96 maxIoThreads = 100 maxWorkerThreads = 100 minFreeThreads = 704 minLocalRequestFreeThreads = 608 |
不好玩。
许多根本原因共有共同的症状,这使得很难在不弄脏应用程序的情况下进行诊断。 :)如果暗示其中某些步骤,请原谅。
一些下一步可能是:
-
查看每个站点的IIS日志,查找类似以下内容的内容:
- HTTP响应代码(5xx,4xx,3xx)
- 请求响应时间
-
查看Windows事件日志
- 应用程序池多长时间循环一次?
- 应用程序错误等
- 验证@vinayc所建议的processModel设置,以确保前任没有"棘手"
-
安装DebugDiag,它是对内存和崩溃相关问题进行一些基本分析的令人惊讶的好工具。
- 这也可以帮助您捕获内存快照,以便以后进行诊断。
- Tess Ferrandez博客可以帮助您进行内存快照分析。
- 了解每个AppPool中正在运行多少个Web应用程序。
- 调查使用"网络花园"可能有助于最大程度地减少受"减速"影响的用户数量
- 是否启用了病毒扫描程序?它在运行吗?如果是这样,请验证排除项。
- 是否有应用程序团队可以帮助您进行故障排除?确定他们是否具有任何有助于诊断问题的自定义应用程序工具。
该行为是否是"新"行为?还是一直在那里?如果为"新",您是否可以跟踪可能导致新行为的部署?
所给出的"减速"行为的描述是否可以归因于apppool回收以及由此导致的应用程序再次启动? ala-第一个请求综合症。
查看日志有助于了解网站/应用程序的使用方式,如果您不拥有代码库,这一点尤其重要。 Logparser是进行某些IIS日志分析(以及其他格式)的出色工具。
祝你好运!
Z
您正在谈论的设置是来自machine.config中
1
2
3
4
5
6
7 autoConfig
maxIoThreads
maxWorkerThreads
minIoThreads
minWorkerThreads
requestQueueLimit
responseDeadlockInterval
通常,您只会找到
该文章虽然过时,但如果您要手动调整这些设置,则是很好的资源。
另一方面,根据您所服务的负载,我会建议两件事(如果您还没有尝试过的话)
- 积极使用输出缓存-即使数据是动态的,缓存30-60秒也可以显着提高负载
- 如果您怀疑某些请求占用了太多线程,则尝试将这些资源移到不同的应用程序池下(您可以使用具有不同子域的不同网站,也可以使用不同的虚拟目录/应用程序并选择不同的应用程序池)