#multithreading #database-deadlocks
#многопоточность #база данных-взаимоблокировки
Вопрос:
Я написал простое приложение, которое создает параллельный словарь из 999 элементов, а затем запускает 50 потоков, используя этот ThreadPool.SetMinThreads() метод. Затем я перебираю 999 словарных записей и обновляю запись в базе данных, чтобы отметить, что запись была обработана.
При запуске приложения я вижу, что потоки запущены, а затем я могу запустить SQL-запрос, чтобы увидеть обновляемые записи. Пока все это работает довольно хорошо. Когда некоторые из начальных потоков завершаются, запускается следующая партия потоков (это именно то, что я хочу, чтобы это делалось). Я все еще вижу, что мои записи в базе данных все еще обновляются, сообщая мне, что приложение работает должным образом. Я все еще вижу, как создаются новые потоки, а затем я получаю тупик. Когда я смотрю на взаимоблокировку, это происходит с одного из начальных 50 потоков, которые были запущены. Вот где возникает мой вопрос.
Я запускаю приложение на двухъядерном процессоре 3 ГГц с 6 ГБ оперативной памяти. Мой экземпляр SQL Server также запущен на том же компьютере, но я бы не подумал, что это будет проблемой. Приложение является доказательством концепции, но невозможность запуска 50 потоков в среде разработки не выглядит многообещающе. Я знаю, что в производственной среде экземпляр SQL будет находиться на отдельном компьютере, как и приложение. Есть идеи?
Комментарии:
1. Какая тупиковая ситуация — в SQL или в вашем коде?
2. Взаимоблокировки не имеют ничего общего с потреблением памяти, а все, что связано с общим состоянием.
3. Извините, это тупики SQL
4. Нет смысла запускать более 2 потоков с интенсивным использованием процессора одновременно, если у вас только двухъядерный компьютер. Вы просто будете биться.
Ответ №1:
Возможна взаимоблокировка базы данных, если вы обновляете одну и ту же таблицу из нескольких потоков. Похоже, вам нужно повторно запустить неудачный оператор SQL и / или изменить уровень блокировки ваших операторов. Это можно сделать, используя подсказки о блокировке в самом заявлении.
Ответ №2:
Типичная установка Windows легко включает 900 потоков. Проверьте Taskmgr.exe , вкладка «Производительность». Подавляющее большинство из них будут заблокированы в ожидании, пока что-то произойдет. Добавление еще 50 не сильно повлияет на это. Они не будут выполнять много кода, они будут постоянно ждать, пока сервер dbase выполнит свою работу. Таким образом, запуск такого количества потоков не очень полезен, производительность вашего кода полностью зависит от того, насколько быстро механизм dbase может выполнять ваши запросы. Вы можете легко определить по Taskmgr.exe опять же, если загрузка процессора не равна 100%, то добавление дополнительных потоков не поможет.
Нет, взаимоблокировка вызвана кодом, а не нехваткой ресурсов. И держать 50 шаров в воздухе, не уронив ни одного, — очень сложная задача программирования. Используйте окно отладки Debug Windows Threads, чтобы понять, почему поток не продвигается.