поведения ThreadPool: не растет от минимального размера

Question

Я создал свой пул потоков, как это:

ThreadPool.SetMaxThreads(10000, 10000); 
ThreadPool.SetMinThreads(20, 20); 

Однако, мое приложение начало висеть под большой нагрузкой. Это было связано с тем, что рабочие задачи не выполнялись: я использовал ThreadPool.QueueUserWorkItem для запуска некоторых задач, которые, в свою очередь, использовали один и тот же метод для дальнейшей работы в очереди. Это, очевидно, опасно с ограниченным пулом потоков (ситуация с блокировкой), но я использую пул потоков, чтобы не ограничивать максимальные потоки, но уменьшать накладные расходы на потоки.

Я вижу потенциальную ловушку там, но я полагал, что установка максимального количества 10000 потоков в пуле означает, что если элемент был поставлен в очередь, все потоки были заняты, и в пуле не было 10000 потоков, будет создан новый, и там будет обработано задание.

Однако, я изменил к этому:

ThreadPool.SetMaxThreads(10000, 10000); 
ThreadPool.SetMinThreads(200, 200); 

..и приложение начал работать. Если это заставило его начать работать, мне не хватает чего-то о том, как/когда пул потоков расширяется от минимального до максимального размера?

Answer 1

Всякий раз, когда вы используете пул потоков, вы находитесь во власти своего «алгоритма впрыска нити и выхода на пенсию».

Алгоритм не документально подтвержден (что я знаю) и не настраивается.

Если вы используете задачи, вы можете написать свой собственный Task Scheduler

Answer 2

Если ваша логика зависит от минимального количества потоков, необходимо срочно изменить это.

Установка MinThreads из 200 (или даже 20) растрачивает довольно много памяти. Обратите внимание, что MaxThreads здесь не будут иметь значения, вероятно, у вас нет 10 ГБ памяти.

Тот факт, что минута 200 помогает вам, является подозрительной и, как решение, вероятно, очень хрупкой.

Взгляните на обычные образцы Продюсер/Потребители и/или используйте ограниченную очередь для сопряжения своих задач.

Answer 3

Проблема производительности вы описали, похоже на то, что описано в этой статье ASP.NET KB,

http://support.microsoft.com/kb/821268

Подводя итог, вам необходимо тщательно выбрать параметры (в этой статье упоминаются типичные настройки пула потоков ASP.NET по умолчанию, но вы можете применить трюк к своему приложению), а затем настраивать их на основе тестирования производительности и характеристик вашего приложения ,

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

Answer 4

Задача планировщика threadpool состоит в том, чтобы гарантировать, что больше нет потоков TP, чем ядра процессора. Минимум по умолчанию равен числу ядер. Счастливое число с тех пор минимизирует накладные расходы из-за переключения контекста потока. Дважды в секунду планировщик выполняет вход и разрешает выполнение другого потока, если существующие не завершены.

Поэтому у вас будет час и двадцать минут с потоками, которые не заполняются, чтобы добраться до вашего нового максимума. Довольно маловероятно, что 32-битная машина будет зависеть, когда потоки 2000 потребляют всю доступную виртуальную память. У вас есть шанс на него в 64-битной операционной системе с очень большим файлом подкачки. Для предотвращения пейджинговой смерти требуется много оперативной памяти, вам потребуется не менее 12 гигабайт.

Общая диагностика заключается в том, что вы используете потоки TP ненадлежащим образом. Они занимают слишком много времени, обычно вызванные блокировкой ввода-вывода. Регулярный Thread - это правильный выбор для таких видов работ. Это, вероятно, трудно исправить прямо сейчас, тем более, что вы довольны тем, что получили. Повышение минимального уровня действительно быстрое решение. Вам придется вручную настроить его, так как планировщик TP больше не может выполнять разумную работу.