.NET сокращает параллельные потоки при повторяющихся запусках

Question

Есть ли веские основания для того, чтобы .NET сокращал количество параллельных потоков с течением времени?

Я выполняю вычисления во многих проходах, для выполнения которых требуются дни (каждый проход занимает ~ 1 час).Задачи - это чистые вычисления данных в памяти (чтение с диска).Я использую Parallel.For и Parallel.ForEach в нескольких местах, как для основной задачи, так и внутри задачи.Все повторяется во многих проходах.Экземпляры класса располагаются (профилировщик памяти не показывает проблем со временем) должным образом для каждого прохода, и создается новый экземпляр.Он повторяет 100% одну и ту же задачу при каждом проходе, за исключением изменения некоторых чисел в математике (равное количество итераций каждый раз, один и тот же набор данных).

Компьютер имеет шесть ядер, и приложение запускаетсяиспользуя их все.Через некоторое время он использует 5, затем 4, затем 3, а затем 2. Глядя на параллельные стеки (Debug-> Window-> Parallel Stacks), он подтверждает, что работает только то, что многие из них.

Как получается .NETне максимизируете количество потоков на каждом проходе?Регулирует ли он потоки в зависимости от загрузки процессора?

Советы по отладке?Можно ли принудительно использовать число потоков?

Answer 1

Я считаю, что эта статья о параллелизме ThreadPool должна дать некоторые подсказки.

Задачи, созданные методами Parallel, в конечном итоге будут выполняться ThreadPool. Идеальное количество потоков, которое должен использовать ThreadPool, зависит от типа выполняемых задач. Если задачи блокируют много и не имеют большого количества конфликтов, большее количество потоков приведет к более высокой пропускной способности. Для задач с небольшим количеством блокировок и высоким уровнем конкуренции за ограниченные ресурсы, меньшее количество потоков приведет к более высокой пропускной способности.

Благодаря этому свойству ThreadPool в .NET 4 реализует алгоритм "восхождения на холм", в котором он настраивает количество потоков, выполняемых ThreadPool, и реагирует на основе измеренной пропускной способности.

Итак, одну вещь, которую вы можете проверить, это посмотреть, уменьшается ли фактическая производительность задания с уменьшенным количеством потоков. Также возможно, что когда ваше приложение работает, оно все больше и больше сталкивается с дисковыми операциями, а потоки закрываются просто из-за неиспользования.

Что касается принудительного использования ThreadPool определенного количества потоков, я не думаю, что это возможно. Есть ThreadPool.SetMinThreads , но это никогда не работало для меня. Как правило, .NET будет просто игнорировать эти значения и использовать любое количество потоков.