应用程序池设置杀死线程但保留设置
.net 2.0 aspx app / IIS6 在 w3wp.exe 进程应用程序池中创建大量线程。
该应用程序已通过以下设置隔离到其自己的应用程序池：
RECYCLING
回收工作进程（以分钟为单位）：870 回收工作进程（请求数量）：（未勾选） 在以下时间回收工作进程：00:00 最大虚拟内存：（不勾选） 最大使用内存（以 mb 为单位）：1000mb (1gb)
性能
闲置后关闭工作进程（时间以分钟为单位）：20 限制内核请求队列（请求数）：1000 启用CPU监控（%）：85 刷新 CPU 使用次数（以分钟为单位）：5 当 cpu 使用率超过最大 cpu 使用率时执行的操作：NO ACTION（保持 会议） 最大工作进程数：1
HEALTH
启用 ping（选中） 每（秒） ping 工作进程：30 启用快速故障保护（选中） 失败次数：5 时间段（分钟）：5 启动时间限制 - 工作进程必须在（秒）内启动：90 关闭时间限制 - 工作进程必须在（秒）内关闭：90
正常运行将看到 w3wp.exe 进程利用 300MB 内存和 50MB 瑟拉兹。当我的问题发生时，线程数慢慢增加到 10,000 ，在线程被击回 0 之前，内存增加到 1GB。 w3wp.exe 进程 没有关闭，我的用户没有注销（至关重要），即他们保留 他们的会话，并且不必重新登录。尽管标准 50 线程 被杀死在 10, 000 个胭脂线程中。
1）专家能否提供上述应用程序池设置的优点/缺点？
2）“最大使用内存”设置似乎可以解决问题 自动处理这个问题（通过终止线程，保持会话 还活着，但有人能解释为什么吗？ ...我认为线程与无关 会议）。
该应用程序使用基于服务器的会话，但我们存储本地 cookie 以进行身份验证。
.net 2.0 aspx app / IIS6 creating a silly number of threads in w3wp.exe process app pool.
The app has been isolated to its own app pool with the following settings:
RECYCLING
recycle worker processses (in minutes) : 870
recycle worker process (no of requests): (not ticked)
recycle worker processes at the following times: 00:00
max virtual memory: (not ticked)
max used memory (in mb): 1000mb (1gb)
PERFORMANCE
shutdown worker processes after being idle for (time in mins): 20
limit the kernal request queue (number of requests): 1000
enable cpu monitoring (%): 85
refresh cpu usage numbers (in mins): 5
action performed when cpu usage exceeds maximum cpu uses: NO ACTION (keeps
sessions)
max number of worker processes: 1
HEALTH
enable pinging (checked)
ping worker process every (seconds) : 30
enable rapid fail protection (checked)
failures: 5
time period (in mins):5
start time limit - worker process must startup within (seconds): 90
shutdown time limit - worker process must shutdown within (seconds): 90
Normal running would see the w3wp.exe process utilise 300MB ram and 50
therads. When my problem occurs the thread count slowly increases to 10,000
, ram to 1GB before the threads are knocked back to 0. The w3wp.exe process
is NOT shutdown and my users are not logged out (crucially), ie they keep
their session and dont have to log back in . Altough the standard 50 threads
are killed in amongst the 10, 000 rouge threads.
1) Can an expert offer any pros/cons on the above app pool settings ?
2) The "max used mem" setting appears to be doing the trick to
automatiaclly handle this issue (by killing the threads, keeping the session
alive , but can someone explain why ? ... i take it threads are unrelated to
the session).
The app uses server based sessions but we store a local cookie for authentication.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
线程
10k 线程太高了，线程在处理器上跳来跳去的时间比实际工作的时间还要多。又称殴打。
编辑：我在这里假设它是一个 .NET Web 应用程序。
您的应用程序使用ThreadPool还是BackgroundWorkers？看起来您必须使用 IIS 标准线程周围（每个处理器只有大约 4 个）以外的某种机制才能达到 10k 线程。
内存
除了用于工作的内存之外，每个线程还需要内存来跟踪，因此通过绝对的线程量，您可能会达到 1G 限制。
会话（我会活下去！）
应用程序可能设置为将会话状态存储在持久存储或会话状态服务中。既然如此，工作进程就可以安全地回收，而不会丢失用户状态信息。如果会话状态（在 Web.config 中）配置为 In-Proc，则当工作进程回收时，会话状态将丢失。
工作进程回收
另一件值得注意的事情是，在一个工作进程终止之前，另一个工作进程会被设置并开始取代它的位置。在此进程中的某个位置，您可能会看到 w3wp.exe 进程（无论是旧的还是新的）有 0 个线程。
BackgroundWorkers 就像兔子
如果您的线程执行的工作持续时间超过 1 秒（实际上是 1/2 秒），请不要使用 BackgroundWorkers。除非您更改 ThreadPool 的最大线程数（不建议这样做，因为这可能会破坏 .NET 中更深层的功能），否则对可以同时运行的 BackgroundWorkers 的数量没有严格（足够）的限制。在这种情况下，最好使用生产者消费者队列模型。
请访问此网站。这是关于并发编程的很棒的资源，包含大量模型和示例。
Threads
10k threads is insanely high, and your threads are spending more time hopping on and off the processor than doing actual work. aka thrashing.
EDIT: I'm assuming here that it's a .NET web application.
Does your application use a ThreadPool or BackgroundWorkers? It seems like you'd have to be using some mechanism other than IIS's standard thread entourage (which is only around 4 per processor) to reach 10k threads.
Memory
Each thread requires memory to keep track of in addition to the memory it utilizes for work, so by sheer volume of threads, you are probably reaching the 1G limit.
Session (I will survive!)
The application is probably setup to store Session State in persistent storage or the session state service. With this being the case, the worker process can safely be recycled without losing user state information. If the session state was configured (in the Web.config) as In-Proc, then session state would be lost when the worker process recycled.
Work process recycling
One other thing of note, before a worker process dies, another worker process is setup and started to take it's place. It's somewhere in this process that you're probably seeing the w3wp.exe process (either old or new) with 0 threads.
BackgroundWorkers are like rabbits
If your threads are performing work that lasts longer than 1 second (1/2 second really), don't use BackgroundWorkers. Unless you change the ThreadPool's max threads (which is NOT recommended, as this can screw up deeper functionality within .NET), there's not a hard (enough) limit on the number of BackgroundWorkers that can run concurrently. It would be better to use a Producer Consumer Queue model in that case.
Check out this site. It's an awesome resource on concurrent programming with lots of models and examples.