Неловко распараллеливаемые задачи в .NET

Question

Я работаю над проблемой, когда мне нужно выполнить множество смущающих параллелизуемых задач. Задача создается путем чтения данных из базы данных, но совокупность всех задач превысит объем памяти на машине, поэтому задачи должны быть созданы, обработаны и удалены. Мне интересно, что было бы хорошим подходом для решения этой проблемы? Я думаю о следующих двух подходах:

1. Реализация синхронизированной очереди задач. Реализуйте производителя (создателя задач), который считывает данные из базы данных и помещает задачу в очередь (ограничьте число задач, находящихся в данный момент в очереди, постоянным значением, чтобы убедиться, что объем памяти не превышен). Имейте несколько пользовательских процессов (процессор задач), которые читают задачу из очереди, обрабатывают задачу, сохраняют результат и удаляют задачу. Каким было бы большое количество потребительских процессов при таком подходе?

2. Используйте расширение .NET Parallel (PLINQ или параллельное для), но я понимаю, что необходимо создать коллекцию задач (Можем ли мы добавить задачи в коллекцию при обработке параллельно для?). Итак, мы создадим пакет задач - скажем, N задач за раз, обработаем этот пакет задач и прочитаем еще N задач.

Что вы думаете об этих двух подходах?

Answer 1

Используйте ThreadPool с ограниченной очередью, чтобы избежать перегрузки системы.

Если каждая из ваших рабочих задач связана с ЦП, то сначала настройте свою систему так, чтобы количество потоков в вашей системе равнялось количеству аппаратных потоков, которые может запустить ваш компьютер.

Если ваши задачи не связаны с процессором, вам придется поэкспериментировать с размером пула, чтобы найти оптимальное решение для вашей конкретной ситуации

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

По сути, тестируйте, настраивайте, тестируйте, повторяйте, пока не будете довольны.

Answer 2

У меня не было возможности фактически использовать PLINQ, однако я знаю, что PLINQ (например, vanilla LINQ) основан на IEnumerable. Таким образом, я думаю, что это может быть тот случай, когда имеет смысл реализовать производителя задач с помощью блоков итераторов C # (т.е. ключевое слово yield).

Предполагая, что вы не выполняете никаких операций, для которых весь набор задач должен быть известен заранее (например, упорядочивание), я ожидаю, что PLINQ будет использовать только столько задач, сколько может обработать за один раз. Кроме того, эта статья ссылается на некоторые стратегии управления тем, как PLINQ использует потребление входных данных (раздел, озаглавленный «Обработка вывода запроса»).

РЕДАКТИРОВАТЬ : Сравнение PLINQ с ThreadPool.

Согласно этой статье MSDN , эффективное распределение работы для пула потоков вовсе не тривиально, и даже если вы делаете это "правильно", использование TPL обычно демонстрирует лучшую производительность.

Answer 3

Используйте ThreadPool .

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

Answer 4

Похоже на работу для Microsoft HPC Server 2008. Учитывая, что количество задач огромно, вам нужен какой-то менеджер параллельных процессов. Вот что такое HPC-сервер.

http://www.microsoft.com/hpc/en/us/default.aspx

Answer 5

Похоже, Windows Workflow Foundation (WF) может быть полезно для этого. Это также может дать вам некоторые дополнительные преимущества, такие как приостановка / возобновление выполнения ваших задач.

Answer 6

Чтобы дать хороший ответ, нам нужно ответить на несколько вопросов.

Параллельно ли каждая отдельная задача? Или каждая задача является продуктом распараллеливаемой главной задачи?

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