Многопотоковое приложение Control Memory-Hungy

Question

Это ОЧЕНЬ открытый вопрос.

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

Если количество потоков слишком велико, приложение становится мошенническим, пожирает всю доступную память и зависает .. Какой самый эффективный способ использоватьвсе возможности ЦП + ОЗУ (высокопроизводительные вычисления, например, 12 ядер / 16 ГБ ОЗУ) без поднятия системы на колени (что происходит, если запускается «слишком много» одновременных потоков, а «слишком много»)относительное понятие, конечно)

Я должен указать, что у меня есть очередь рабочих буферов с N работниками, каждый раз, когда кто-то заканчивает работу и умирает, новая запускается через очередь.Это работает довольно хорошо, как сейчас.Но я бы хотел избежать «ручного» и «эмпирического» задания количества одновременных потоков и иметь интеллектуальную масштабируемую систему, которая отбрасывает столько потоков за раз, что система может правильно обработать, и останавливаться на«разумное» использование памяти (целевой сервер выделен для приложения, поэтому нет проблем с другими приложениями, кроме системы)

PS: я знаю, что .Net 3.5 поставляется с пулами потоков, а в .Net 4 есть интересныеВозможности TPL, которые я до сих пор обдумываю (я до сих пор никогда не углублялся в это).

PS 2: После прочтения этого поста я был немного озадачен "дономне делай этого "ответы.Хотя я думаю, что такой запрос справедлив для вычислительной программы с высокими требованиями к памяти.

РЕДАКТИРОВАТЬ
После прочтения этого поста Я попытаюсь использовать Функции WMI

Answer 1

Все встроенные возможности потоков в .NET не поддерживают настройку в соответствии с использованием памяти. Вы должны построить это самостоятельно.

Вы можете либо прогнозировать использование памяти, либо реагировать на нехватку памяти. Альтернативы:

1. Посмотрите на объем свободной памяти в системе, прежде чем запускать новое задание. Если оно меньше 500 МБ, подождите, пока не освободится достаточно.
2. Запускайте задачи по мере их поступления и дросселируйте, как только некоторые из них начнут выходить из строя из-за OOM. Перезапустите их позже. Эта альтернатива отнимает много времени, потому что ваш процесс будет выполнять сбор мусора как сумасшедший, чтобы избежать OOM.

Я рекомендую (1).

Вы можете посмотреть на свободную системную память или на использование памяти своими собственными процессами. Чтобы использовать память, я рекомендую просмотреть частные байты с помощью класса Process.

Если вы отводите 1 ГБ буфера в вашей системе на 16 ГБ, вы работаете с эффективностью 94% и довольно безопасны.