38

Is there a magic number or formula for setting the values of SetMaxThreads and SetMinThreads for ThreadPool? I have thousands of long-running methods that need execution but just can't find the perfect match for setting these values. Any advise would be greatly appreciated.

Benny
  • 3,899
  • 8
  • 46
  • 81

3 Answers3

54

The default minimum number of threads is the number of cores your machine has. That's a good number, it doesn't generally make sense to run more threads than you have cores.

The default maximum number of threads is 250 times the number of cores you have on .NET 2.0 SP1 and up. There is an enormous amount of breathing room here. On a four core machine, it would take 499 seconds to reach that maximum if none of the threads complete in a reasonable amount of time.

The threadpool scheduler tries to limit the number of active threads to the minimum, by default the number of cores you have. Twice a second it allows one more thread to start if the active threads do not complete. Threads that run for a very long time or do a lot of blocking that is not caused by I/O are not good candidates for the threadpool. You should use a regular Thread instead.

Getting to the maximum isn't healthy. On a four core machine, just the stacks of those threads will consume a gigabyte of virtual memory space. Getting OOM is very likely. Consider lowering the max number of threads if that's your problem. Or consider starting just a few regular Threads that receive packets of work from a thread-safe queue.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Please take a look at [my related question](http://stackoverflow.com/q/7974559/75500 "Run a batch of processes and report progress from each of them"), one user suggested there I should use the [ThreadPool], according to what you say, I don't think it's a good idea, perhaps you can help me out. – Shimmy Weitzhandler Nov 03 '11 at 01:39
  • 4
    @Hans Passant: this is barely correct, first of all the default maximum number of threads depends on the .NET Framework Version that is used by the application (e.g. 25 per core in 2.0). Second thing is that increasing the minimum number of threads results in threads being able to launch without delay, until the minimum number is reached (they will not launch if they aren't needed). If the minimum delay is reached new threads will only be created with a delay inbetween, resulting in a performance increasement on long operations (>500ms), but in a performace drop on short operations. – haze4real Nov 09 '12 at 00:14
  • 1
    @HansPassant - if one is creating threads that may get blocked waiting for external IO, I think there are situations where the "best" minimum would indeed be higher than the number of cores. Because a "blocked" thread still "counts" towards the minimum, right? (I understand this won't matter for more than a few seconds, because after that the scheduler will have created those extra threads anyway. Just making sure I understand the reasoning.) – ToolmakerSteve Mar 04 '18 at 18:18
9

Typically, the magic number is to leave it alone. The ThreadPool does a good job of handling this.

That being said, if you're doing a lot of long running services, and those services will have large periods where they're waiting, you may want to increase the maximum threads to handle more options. (If the processes aren't blocking, you'll probably just slow things down if you increase the thread count...)

Profile your application to find the correct number.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • If I were to change the max threads (and min threads?) there are two parameters, worker threads and completion port threads. What's the completion port thread count for?? – Benny Jan 11 '10 at 18:42
  • Also, if I leave the ThreadPool alone, without setting min/max threads I run into an OutOfMemoryException and all threads fail. – Benny Jan 11 '10 at 18:44
  • 3
    That's a different issue - you can reduce the amount of work by throttling it, but running out of memory really has nothing to do with threading... – Reed Copsey Jan 11 '10 at 20:14
  • @ReedCopsey Can you please help me with [this related question](http://stackoverflow.com/questions/7974559/run-a-batch-of-processes-and-report-progress-from-each-of-them)? Thanks – Shimmy Weitzhandler Nov 03 '11 at 11:58
  • it's not a good idea to "throttle" work to avoid a OOM-Exception caused by too much threads being used by the ThreadPool. The idea of the ThreadPool is to manage asynchronous workload, so you should leave the "throttling" to the ThreadPool and not do it yourself. If you run out of memory because of the ThreadPool you should decrease the MaxThreads (1 Thread approximately needs 1 MB). – haze4real Nov 09 '12 at 00:05
  • @haze4real - presumably OOM isn't happening because of the ThreadPool *directly*, but because the programmer is creating threads that each use *a lot* of memory. In which case, "throttling" is *exactly* what the programmer needs to do: limit the number of active threads *for that particular task*. However, I agree that messing with the threadpool parameters isn't a great way to do the throttling - instead it should be "throttled' at the source: the code that launches these threads should be tracking how many are active, and block itself whenever it hits its self-imposed limit. – ToolmakerSteve Mar 04 '18 at 18:24
7

If you want better control, you might want to consider NOT using the built-in ThreadPool. There is a nice replacement at http://www.codeproject.com/KB/threads/smartthreadpool.aspx.

Michael Bray
  • 14,998
  • 7
  • 42
  • 68
  • I've attempted to use SmartThreadPool, but to no avail. After I queued all of the work items, I attempted to use WaitForIdle (I have post-execution logic to run) and it never blocks, just moves right on. Might be between the keyboard and the computer, but haven't figured that one out yet – Benny Jan 11 '10 at 18:41
  • 1
    I know this post is 10 years old. But for what it's worth... In my professional experience it's, in almost all cases, a bad decision to think that a "custom" implementation would perform any better than what the .NET teams have made over many years. Of cause there could be extreme cases where the general-purpose threadpool implementation would be suboptimal, but this is very rare. – Hulvej May 04 '21 at 08:07