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

Question

Я настроил свой пул потоков следующим образом:

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Если вы используете Задачи, вы можете написать свой собственный Планировщик задач

Answer 3

Описанная вами проблема с производительностью аналогична той, которая описана в этой статье ASP.NET KB,

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

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

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

Answer 4

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

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

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

Взгляните на обычные шаблоны «производитель / потребитель» и / или используйте ограниченную очередь для объединения ваших задач.