Смущающе параллелизуемые задачи в .NET.

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

EDIT: Сравнение PLINQ с ThreadPool.

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

Answer 5

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

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

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

Answer 6

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