Які можливі причини, щоб тримати тривалий час виконання 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 викликається, коли об'єднане з'єднання повторно використовується. Я бачив припущення, що це може статися через сторонні сліди , але це, мабуть, не так.

Я прочитав, що робить сервер, коли викликається паросток, але я не вважаю, що жодне з них було б проблематичним у цьому випадку - код не залишає відкритих транзакцій або величезних тимчасових таблиць, які потрібно буде очистити.

Я також переглянув /server/199974/sp-reset-connection-taking-a-long-time-to-run, але це не було корисно.

EDIT (2013-12-23): У всіх випадках читання і записування дорівнюють 0, а процесор майже завжди дорівнює 0 (лише два екземпляри ненульового процесора, обидва в 16 мс).

Нарешті отримав трохи часу, щоб написати більш детальну відповідь.

Зазвичай є три основні причини, як проста процедура, як, наприклад sp_reset_connection, потребуватиме тривалого часу.

1. Ви чекаєте ресурсів процесора
2. Ви заблоковані десь із замком (можливо, через DML або конкуруючу транзакцію)
3. Ваша мережа повільна, і для повернення результату клієнту потрібно тривалий час

Оголошення 1) Якщо ви чекаєте ресурсів процесора, це повинно відображатися як сигнал чекає. Будь ласка, дивіться мій коментар до вашого питання про те, як поставити діагноз, якщо це проблема

Оголошення 2) Якщо ви чекаєте блокування, це найкраще діагностувати шляхом порівняння двох знімків sys.dm_os_wait_stats. Дивіться цю статтю про те, як це зробити:

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

Якщо ви бачите довго очікування LCK_ [Щось], запитайте, sys.dm_tran_locksщоб відстежити, які об’єкти блокуються. У вашому випадку я б очікував побачити якусь форму замків SCH- [Щось]>, що блокує вас.

Оголошення 3) Найпростіший спосіб діагностувати проблеми з мережею, спочатку шукати OLEDB і ASYNC_NETWORK_IO чекає на кроці 2 (якщо ви довго чекаєте мережу, з’явиться один із них). Якщо таких очікувань велике, скористайтеся xperf -on latencyпрограмою для моніторингу мережі, наприклад, netmon або wireshark, щоб перевірити свої затримки. Якщо мережа виглядає повільно, це також може бути викликано тим, що сервер додатків, що викликає, не реагує на швидку відповідь на з'єднання, яке переробляється.

Щойно я натрапив на статтю KB про помилку, яка може бути пов’язана з цією проблемою. У FIX: Проблеми з продуктивністю виникають, коли активність блокування бази даних збільшується в SQL Server (KB 2926217), одним із описаних симптомів є те, що sp_reset_connectionзавершення може зайняти тривалий час. Виправлення включено до таких оновлень:

• Сукупне оновлення 17 для SQL Server 2008 SP3
• Сукупне оновлення 13 для SQL Server 2008 R2 SP2
• Сукупне оновлення 9 для SQL Server 2012 SP1
• Сукупне оновлення 1 для SQL Server 2014

Сервер, на якому я спостерігав таку поведінку, запускав SQL Server 2008 SP3 з накопичувальним оновленням 5, тому, можливо, він відчував цю помилку. Я ще не пробував накопичувального оновлення (проблема не повторюється весь час), тому я не можу перевірити, чи виправить це чи ні. Однак я хотів надати інформацію на випадок, якщо хтось мав ті самі симптоми.