Каковы возможные причины выполнения sp_reset_connection длительного времени?

Почему выполнение sp_reset_connectionсистемной хранимой процедуры занимает больше нескольких миллисекунд, если смотреть через SQL Server Profiler?

Я взял простую трассировку из производственной системы, используя SQL Server Profiler, а затем использовал SqlNexus для ее анализа. SqlNexus указывает, что sp_reset_connection имеет наибольшую совокупную продолжительность - 33% от общей трассы. Наблюдаемая продолжительность колеблется от 0-7 секунд (от 12 до 6 833 270 микросекунд), но в среднем составляет 0,956 с.

Я понимаю, что sp_reset_connection вызывается, когда пул соединения снова используется. Я видел предположение, что это может происходить из-за посторонних следов , но, похоже, это не так.

Я читал, что делает сервер, когда вызывается sproc, но я не думаю, что что-то из этого будет проблематичным в этом случае - код не оставляет открытых транзакций или огромных временных таблиц, которые необходимо будет очистить.

Я также посмотрел на /server/199974/sp-reset-connection-taking-a-long-time-to-run, но это не помогло.

РЕДАКТИРОВАНИЕ (2013-12-23): во всех случаях чтение и запись равны 0, а ЦП почти всегда равен 0 (только два экземпляра ненулевого ЦП, оба при 16 мс).

sql-server sql-server-2008

— Целостный разработчик
источник

Какие значения вы видите для чтения и записи в этом событии?

— Мартин Смит

Можете ли вы предоставить больше информации о том, какие запросы вы выполняете. Особенно интересные детали, такие как, длинные или сложные транзакции, обработка XML, временные таблицы?

— Эдвард Дортланд

@Martin читает и пишет 0. Обновил вопрос. (Не было доступа к данным в выходные дни.)

— Целостный разработчик

@EdwardDortland большинство запросов - это довольно простые операции выбора и обновления без явных транзакций или использования временных таблиц. Фактически, обычно фактические запросы, выполняемые на этих соединениях, выполняются довольно быстро - всего несколько мс.

— Целостный разработчик

@HolisticDeveloper - Я экспериментировал с выходом из открытой транзакции и мог видеть ненулевое чтение и запись там, так что согласитесь, что тогда это не выглядит так. Эта ситуация более или менее постоянна? если это так , я бы запустить расширенный захват событий трассировки RPC:Starting, RPC:Completedи ждать типов в течение короткого периода затем просмотреть данные , чтобы увидеть , что ждать типы ИСП сталкивается в течение этого времени.

— Мартин Смит

Ответы:

Наконец-то есть время написать более подробный ответ.

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

Вы ждете ресурсов процессора
Вы заблокированы где-то на блокировке (возможно, в результате DML или конкурирующей транзакции)
Ваша сеть работает медленно и требуется много времени, чтобы вернуть результат клиенту

Объявление 1) Если вы ожидаете ресурсов процессора, это должно отображаться при ожидании сигнала. Пожалуйста, смотрите мой комментарий на ваш вопрос о том, как диагностировать, если это проблема

Объявление 2) Если вы ожидаете блокировки, это лучше всего диагностируется путем сравнения двух снимков sys.dm_os_wait_stats. Смотрите эту статью о том, как это сделать:

http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

Если вы видите долгое ожидание LCK_ [Something], запросите, sys.dm_tran_locksчтобы отследить, какие объекты заблокированы. В вашем случае я бы ожидал, что какая-то форма SCH- [Something]> блокирует вас.

Объявление 3) Самый простой способ диагностики проблем в сети - сначала поискать OLEDB, а ASYNC_NETWORK_IO ожидает в шаге 2 (если вы долго ждете сеть, появится один из них). Если эти ожидания высоки, используйте xperf -on latencyпрограмму мониторинга сети, такую как netmon или wireshark, чтобы проверить ваши задержки. Если сеть выглядит медленной, это также может быть вызвано тем, что вызывающий сервер приложений недостаточно быстро реагирует на перезапускаемое соединение.

— Томас Кейсер
источник

Я еще не видел, чтобы проблема повторялась, поэтому я не могу использовать предоставленный ответ для дальнейшей диагностики на данном этапе. Однако я принимаю ответ на основании вашей репутации эксперта по производительности SQL Server.

— Целостный разработчик

Я только что натолкнулся на статью в КБ об ошибке, которая может быть связана с этой проблемой. В FIX: Проблемы с производительностью возникают при увеличении активности блокировки базы данных в SQL Server (KB 2926217), один из описанных симптомов - это sp_reset_connectionможет занять много времени. Исправление включено в следующие обновления:

Накопительное обновление 17 для SQL Server 2008 с пакетом обновления 3 (SP3)
Накопительное обновление 13 для SQL Server 2008 R2 с пакетом обновления 2
Накопительное обновление 9 для SQL Server 2012 SP1
Накопительное обновление 1 для SQL Server 2014

Сервер, на котором я наблюдал такое поведение, работал под управлением SQL Server 2008 с пакетом обновления 3 (SP3) с накопительным обновлением 5, поэтому возможно, что он сталкивался с этой ошибкой. Я еще не пробовал накопительное обновление (проблема не повторяется все время), поэтому я не могу проверить, исправит ли это или нет. Тем не менее, я хотел предоставить информацию на случай, если у кого-то будут такие же симптомы.

— Целостный разработчик
источник