Слепое создание большого количества потоков, чтобы ускорить выполнение операции, не является хорошим решением и почти никогда не работает (за исключением, к счастью, возможно). Имейте в виду, что каждому потоку выделяется свой собственный стек, который по умолчанию составляет 1 МБ. Так что в случае, если вы получите 1000 потоков, которые будут использовать 1 ГБ ОЗУ, как это.
Если вы нажмете на БД, то параллельная работа с большой вероятностью будет ограничена дисковым вводом / выводом, поэтому использование большего количества потоков может даже ухудшить ситуацию.
Также следует помнить, что асинхронные операции выполняются в потоках пула потоков, и если вы связываете их все со своей собственной работой, вы можете столкнуться с проблемой, приводящей к истощению этих операций (что означает, что они могут быть выполнены никогда или очень поздно). Пул потоков предназначен для запуска только краткосрочных задач. Если вам нужны долго выполняющиеся задачи, используйте другой пул потоков (например, SmartThreadPool ) или создайте собственный набор потоков для обработки работы.
В зависимости от ваших операций SQL вы можете столкнуться с проблемой фрагментации кучи больших объектов. Объекты размером более 85 000 байт помещаются в LOH, который не сжимается, и вы можете столкнуться с неожиданными исключениями OOM. Поэтому проверьте, создаете ли вы большие массивы или списки объектов.
В противном случае: Используйте средства отладки для Windows , чтобы создать дамп памяти и посмотреть, какие объекты у вас есть, и где хранятся ссылки, чтобы сохранить их живыми. В качестве альтернативы вы можете использовать профилировщик памяти .NET, но большинство действительно полезных не бесплатны (однако обычно они идут с оценочным периодом X дней).