#sql-server
#sql-server
Вопрос:
Я использую базу данных SQL Server с Nodejs. Я использую пул соединений для выполнения различных запросов. Когда я запускаю sp_who2 , я вижу, что существует почти 20 процессов, которые имеют статус sleeping и команду, ожидающие команды.
Должен ли я продолжить и удалить эти процессы? Я читал в каком-то другом сообщении, что это происходит, когда вы создаете транзакцию в SQL Server, но не закрываете / фиксируете / откатываете эту транзакцию. Я не вижу ни одного пункта в моем приложении, где я не совершал или не откатывал транзакцию по ошибке. Поэтому я не уверен, откуда возникла ошибка.
У меня есть предчувствие, что оставление этих процессов там вызовет проблемы с таймаутом запросов в будущем. Есть ли способ узнать, какой запрос вызвал спящее, но ожидающее состояние?
Комментарии:
1. вам нужно показать свой код
2. Ваш процесс заблокирован каким-то другим процессом, который, предположительно, имеет блокировку таблицы для некоторой таблицы, которая используется в вашем коде. Определите другой процесс и завершите его, и ваш код будет запущен.
3. У вас возникла проблема? Постоянно ли растет число подключений? Удерживаются ли замки?
Ответ №1:
Обычно я вижу много спящих подключений. Я считаю это нормальным. Если у вас есть спящие соединения с открытыми транзакциями и блокировками, вам необходимо провести расследование. Я бы попытался идентифицировать хост и PID, удерживающий блокировку. В некоторых случаях решение представляет собой вежливый разговор с лицом, ответственным за то, что они не закрыли свою транзакцию.
Пул подключений — это пул подключений к SQL Server. Они будут простаивать и спать, если они не используются. Как правило, для соединений в пуле существует тайм-аут. (Например, если вы посмотрите на панель управления ODBC, на вкладке объединения пулов соединений обычно отображается 60-секундный тайм-аут. Он также может всегда поддерживать минимальное количество незанятых подключений.) Проверьте, есть ли у вас минимальное количество незанятых подключений. Как только вы узнаете свой тайм-аут, убедитесь, что время ожидания соединений истекло, как и ожидалось … в конце концов. Если нет, я бы искал утечку соединения или проблему с пулом соединений. Приложение освобождает соединение после завершения? Должен ли GC запускаться до прекращения соединения?
Несколько лет назад возникла проблема, из-за которой соединение могло вернуться в пул с открытой транзакцией. Только после того, как соединение было подготовлено к повторному использованию, оно было окончательно сброшено. Эта проблема была исправлена.
Еще одной прошлой проблемой было разорванное соединение. Например, если SQL Server был перезагружен, все незанятые соединения будут разорваны. Однако это было проверено только после того, как было запрошено соединение. Для каждого соединения в пуле перед его заменой требовалось время ожидания при сбое соединения. Это был ЛАВАШ.