Почему выполнение 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 мс).
источник
RPC:Starting,RPC:Completedи ждать типов в течение короткого периода затем просмотреть данные , чтобы увидеть , что ждать типы ИСП сталкивается в течение этого времени.Ответы:
Наконец-то есть время написать более подробный ответ.
Как правило, есть три основные причины, по которым простая процедура, такая как,
sp_reset_connectionможет занять много времени.Объявление 1) Если вы ожидаете ресурсов процессора, это должно отображаться при ожидании сигнала. Пожалуйста, смотрите мой комментарий на ваш вопрос о том, как диагностировать, если это проблема
Объявление 2) Если вы ожидаете блокировки, это лучше всего диагностируется путем сравнения двух снимков
sys.dm_os_wait_stats. Смотрите эту статью о том, как это сделать:Если вы видите долгое ожидание LCK_ [Something], запросите,
sys.dm_tran_locksчтобы отследить, какие объекты заблокированы. В вашем случае я бы ожидал, что какая-то форма SCH- [Something]> блокирует вас.Объявление 3) Самый простой способ диагностики проблем в сети - сначала поискать OLEDB, а ASYNC_NETWORK_IO ожидает в шаге 2 (если вы долго ждете сеть, появится один из них). Если эти ожидания высоки, используйте
xperf -on latencyпрограмму мониторинга сети, такую как netmon или wireshark, чтобы проверить ваши задержки. Если сеть выглядит медленной, это также может быть вызвано тем, что вызывающий сервер приложений недостаточно быстро реагирует на перезапускаемое соединение.источник
Я только что натолкнулся на статью в КБ об ошибке, которая может быть связана с этой проблемой. В FIX: Проблемы с производительностью возникают при увеличении активности блокировки базы данных в SQL Server (KB 2926217), один из описанных симптомов - это
sp_reset_connectionможет занять много времени. Исправление включено в следующие обновления:Сервер, на котором я наблюдал такое поведение, работал под управлением SQL Server 2008 с пакетом обновления 3 (SP3) с накопительным обновлением 5, поэтому возможно, что он сталкивался с этой ошибкой. Я еще не пробовал накопительное обновление (проблема не повторяется все время), поэтому я не могу проверить, исправит ли это или нет. Тем не менее, я хотел предоставить информацию на случай, если у кого-то будут такие же симптомы.
источник