ThreadPool SetMinThreads-设置它的影响 [英] ThreadPool SetMinThreads - the impact of setting it

问题描述

我试图了解设置ThreadPool.SetMinthreads的影响.我在一个Azure App Service中运行了多个虚拟应用程序.我的理解是所有这些虚拟应用程序将共享应用程序池，并且只有一个工作进程(假设应用程序池的最大工作进程为1).

I am trying to understand the impact of setting ThreadPool.SetMinthreads. I have multiple virtual applications running in one Azure App Service. My understanding is that all these virtual applications will share the App Pool, and will have only one worker process (Assuming the App Pool's max worker process will be 1).

我有以下两个问题.

1. 在此设置中，如果我将ThreadPool.SetMinThreads设置为100个工作线程和IO线程，我是否可以安全地假设每个应用程序域在加载时将具有100个工作线程和100个IO线程?确切地说，ThreadPool.SetMinThreads适用于AppDomain，工作进程或应用程序池吗? ThreadPool的范围是什么?
2. 我还假定系统可以产生的最大线程数没有限制，因为它由基础主机的容量决定.这意味着，如果我未明确设置ThreadPool.SetMaxThreads，则系统将生成新线程，并且如果有连续负载直到CPU/内存达到最大值，系统将继续执行该操作.我基于以下声明支持我的假设:

1. In this setup, if I set ThreadPool.SetMinThreads to let's say 100 worker threads and IO threads, can I safely assume that each app domain will have 100 worker threads and 100 IO threads when it is loaded? To be precise, the ThreadPool.SetMinThreads applies within the AppDomain, or Worker Process or App Pool? What is the scope of ThreadPool?
2. I also assume there is no limitation on the max threads the system can spawn as it is determined by the underlying host's capacity. This means, if I do not explicitly set ThreadPool.SetMaxThreads, the system will spawn new threads and will continue to do it if there is a continuous load till CPU/Memory spikes to the max. I am basing on the below statement to support my assumption:

例如，进程和线程需要物理内存，虚拟 内存和池内存，因此， 能否在给定的Windows系统上创建最终取决于 这些资源之一，取决于流程或 创建线程，并首先遇到哪个约束. https://blogs.technet.microsoft.com/markrussinovich/2009/07/05/pushing-the-limits-of-windows-processes-and-threads/

Process and threads, for example, require physical memory, virtual memory, and pool memory, so the number of processes or threads that can be created on a given Windows system is ultimately determined by one of these resources, depending on the way that the processes or threads are created and which constraint is hit first. https://blogs.technet.microsoft.com/markrussinovich/2009/07/05/pushing-the-limits-of-windows-processes-and-threads/

推荐答案

MinThreads可以控制无延迟产生的工作线程数.

The MinThreads governs how many worker threads will be spawned without a delay.

每当您执行需要线程池中的线程(无论是工作线程还是IOCP池)的操作时，系统都会首先查看是否有空闲线程.

Whenever you do something that requires a thread from the thread pool (whether worker or IOCP pool), the system will first see if there is a free thread.

如果没有，它将查看当前产生了多少个线程.如果该数目小于MinThreads，它将立即产生一个新线程.否则，它会等待一小段时间，通常约为300-500ms，尽管这取决于系统.如果仍然没有空闲线程，它将生成一个新线程.

If not, it looks to see how many threads are currently spawned. If that number is less than MinThreads, it immediately spawns a new thread. Otherwise it waits a short time, usually around 300-500ms, though that is system dependent. If there is still no free thread, it will then spawn a new thread.

当然，这仍然受MaxThreads的限制.

Of course, this all is still limited by MaxThreads.

总而言之，IIS非常擅长根据您的计算机确定一个合理的数字，并且在大多数情况下，最好不要理会它；如果您只是担心要处理请求，那么我不会亲自处理它.另一方面，如果您自己生成许多后台任务，那么这可能是明智的.我强烈建议您在实际进行更改之前先进行衡量.

All that said, IIS is very good at figuring out a sensible number based on your machine and in most cases you are best to leave it alone; if you are just worried about serving requests then I wouldn't touch it personally. If, on the other hand, you are spawning a lot of background tasks yourself then it may be sensible. I'd strongly encourage you to measure it before you actually make changes.

尽管...将MinThreads设置为100几乎没有害处，特别是因为系统无论如何都只会启动其实际需要的线程数

Though... Setting MinThreads to 100 is rarely harmful, especially as the system will only start the number of threads it actually needs anyway

这篇关于ThreadPool SetMinThreads-设置它的影响的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！