应用程序池设置杀死线程但保持设置

时间:2009-11-17 16:22:30

标签: multithreading iis-6 memory-leaks pool

.net 2.0 aspx app / IIS6在w3wp.exe进程应用程序池中创建了一个愚蠢的线程数。

应用已使用以下设置隔离到自己的应用池:

RECYCLING

回收工人流程(以分钟为单位):870 回收工作进程(没有请求):(未勾选) 在以下时间回收工作进程:00:00 最大虚拟内存:(未勾选) 最大使用内存(以mb为单位):1000mb(1gb)

效果

空闲后关闭工作进程(分钟内的时间):20 限制内核请求队列(请求数):1000 enable cpu monitoring(%):85 刷新CPU使用数量(分钟):5 当cpu使用超过最大cpu使用时执行的操作:NO ACTION(保持 会议) 最大工作进程数:1

启用ping(已选中) ping工作进程每(秒):30 启用快速失效保护(已选中) 失败:5 时间段(分钟):5 开始时间限制 - 工作进程必须在(秒)内启动:90 关闭时间限制 - 工作进程必须在(秒)内关闭:90

正常运行会看到w3wp.exe进程使用300MB ram和50 therads。当我的问题发生时,线程数慢慢增加到10,000 ,在线程被敲回0之前,ram为1GB.w3wp.exe进程 不关闭,我的用户没有注销(至关重要),即他们保持 他们的会话,不必重新登录。尽管标准的50个线程 在10,000个胭脂线中被杀死。

1)专家可以在上述应用程序池设置中提供任何优缺点吗?

2)“max used mem”设置似乎正在诀窍 自动处理这个问题(通过杀死线程,保持会话 活着,但有人可以解释为什么? ...我认为它与线程无关 会议)。

该应用程序使用基于服务器的会话,但我们存储了本地cookie以进行身份​​验证。

1 个答案:

答案 0 :(得分:2)

<强>线程

10k个线程非常高,并且你的线程花费更多的时间在处理器上和跳出处理器而不是实际工作。又名捶打。

编辑:我在这里假设它是一个.NET Web应用程序。

您的应用程序是否使用ThreadPool或BackgroundWorkers?看起来你必须使用IIS的标准线程随行数(每个处理器只有大约4个)以外的一些机制来达到10k线程。

<强>内存

除了用于工作的内存之外,每个线程都需要内存来跟踪记录,因此通过大量的线程,您可能达到了1G的限制。

会话(我会活下来!)

应用程序可能设置为在持久存储或会话状态服务中存储会话状态。在这种情况下,可以安全地回收工作进程而不会丢失用户状态信息。如果会话状态(在Web.config中)配置为In-Proc,则当工作进程被回收时,会话状态将丢失。

工作流程回收

另外需要注意的是,在工作进程终止之前,会设置另一个工作进程并开始占用它。在这个过程中,您可能会看到w3wp.exe进程(旧的或新的)有0个线程。

BackgroundWorkers就像兔子

如果您的线程执行的工作持续时间超过1秒(确实是1/2秒),请不要使用BackgroundWorkers。除非您更改ThreadPool的最大线程(不推荐这样做,因为这可能会破坏.NET中更深层次的功能),否则可以同时运行的BackgroundWorkers数量不会有很多(足够)限制。在这种情况下,最好使用Producer Consumer Queue模型。

结帐this site。这是一个很棒的资源,可以使用大量的模型和示例进行并发编程。