Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Спонтанная просадка производительности  [new]
SergASh
Member

Откуда:
Сообщений: 167
Привет всем!

Есть хранимая процедура, в ней около 75 statement'ов. Запускается она одновременно из разных клиентов (ASP.NET).
Почти всегда отрабатывает быстро, но иногда зависает на десятки минут. Параметры, с которыми она была вызвана
при зависании, мне известны. Увы, при вызове из SSMS с теми же параметрами все опять работает быстро, так что
дело не в параметрах.

В кеше планов лежит ровно один элемент по этой процедуре, так что тут дело и не в том, что соединения SSMS и ASP.NET
имеют разные свойства и выполняют одно и то же по разным планам.

Запускаю вот такую диагностику и вижу несколько сеансов, выполняющих эту процедуру и застрявших на одном и
том же statement'е, который вставляет данные во временную таблицу.

SELECT req.[session_id] AS [SPID]
      ,req.status AS [Status]
      ,req.command AS [Command]
      ,DB_NAME( req.database_id ) AS [Database]
      ,CASE
         WHEN req.[statement_start_offset] > 0
         --The start of the active command is not at the beginning of the full command text
         THEN CASE req.[statement_end_offset]
                WHEN -1
                --The end of the full command is also the end of the active statement
                THEN SUBSTRING(sqltext.TEXT, (req.[statement_start_offset]/2) + 1, 2147483647)
                --The end of the active statement is not at the end of the full command
                ELSE SUBSTRING(sqltext.TEXT, (req.[statement_start_offset]/2) + 1, (req.[statement_end_offset] - req.[statement_start_offset])/2)
              END
         --1st part of full command is running
         ELSE CASE req.[statement_end_offset]
                WHEN -1
                --The end of the full command is also the end of the active statement
                THEN RTRIM(LTRIM(sqltext.[text]))
                --The end of the active statement is not at the end of the full command
                ELSE LEFT(sqltext.TEXT, (req.[statement_end_offset]/2) +1)
              END
       END AS [Current Statement]
      ,sqltext.[text] AS [Full Statement]
      ,req.cpu_time AS [CPU Time]
      ,req.total_elapsed_time AS [Elapsed Time]
  FROM sys.[dm_exec_requests] req
    CROSS APPLY sys.[dm_exec_sql_text](req.[sql_handle]) sqltext
  WHERE 1=1
        AND req.session_id > 50
        AND req.session_id <> @@SPID
        AND DB_NAME( req.database_id ) in ( 'my-db', 'tempdb' )
  ORDER BY req.[session_id], req.[request_id]

Далее, я посмотрел на sys.dm_os_waiting_tasks и обнаружил, что тип ожидания всегда SLEEP_TASK. Но это вроде как невинное ожидание?

Сам план вроде бы нормальный, ну и по нему же в большинстве случаев все работает быстро.

Вопрос: что дальше делать? Как понять чего именно она ждет?

Спасибо.
по традиции :)
Microsoft SQL Server 2014 - 12.0.2000.8 (X64)
Feb 20 2014 20:04:26
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )
7 июн 18, 11:37    [21475232]     Ответить | Цитировать Сообщить модератору
 Re: Спонтанная просадка производительности  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
SergASh,

автор
Сам план вроде бы нормальный

это да....

dm_exec_requests - blocking_session_id скорее всего не ноль, вот все и ждет пока разойдутся
7 июн 18, 11:55    [21475315]     Ответить | Цитировать Сообщить модератору
 Re: Спонтанная просадка производительности  [new]
SergASh
Member

Откуда:
Сообщений: 167
TaPaK,

blocking_session_id ноль во всех зависших сессиях
7 июн 18, 12:51    [21475653]     Ответить | Цитировать Сообщить модератору
 Re: Спонтанная просадка производительности  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5111
SergASh
Параметры, с которыми она была вызвана
при зависании, мне известны. Увы, при вызове из SSMS с теми же параметрами все опять работает быстро, так что дело не в параметрах.
из SSMS вызывали сразу же или "на следующий день"?
SergASh
и вижу несколько сеансов, выполняющих эту процедуру и застрявших на одном и
том же statement'е, который вставляет данные во временную таблицу.
и что происходит с tempdb в это время?
7 июн 18, 13:34    [21475878]     Ответить | Цитировать Сообщить модератору
 Re: Спонтанная просадка производительности  [new]
Eleanor
Member

Откуда:
Сообщений: 2859
SergASh
Далее, я посмотрел на sys.dm_os_waiting_tasks и обнаружил, что тип ожидания всегда SLEEP_TASK. Но это вроде как невинное ожидание?

Из описания типа ожидания:
This wait type is a general wait indicating that a thread is waiting for some event to occur, including background task scheduling, during hash spills to tempdb, and for some query plan exchange operators where the wait isn’t tracked by either CXPACKET or EXECSYNC waits.

У вас на плане 4 штуки hash match. Возможно, tempdb тормозит.
7 июн 18, 13:50    [21475948]     Ответить | Цитировать Сообщить модератору
 Re: Спонтанная просадка производительности  [new]
Mr. X
Member

Откуда:
Сообщений: 21
по традиции :)
Microsoft SQL Server 2014 - 12.0.2000.8 (X64)
Feb 20 2014 20:04:26
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )


Таки вы ни разу не патчили свой SQL?
Я уже не спрашиваю за обслуживание.
7 июн 18, 14:14    [21476053]     Ответить | Цитировать Сообщить модератору
 Re: Спонтанная просадка производительности  [new]
SergASh
Member

Откуда:
Сообщений: 167
Дедушка
из SSMS вызывали сразу же или "на следующий день"?

Вызывал в то самое время, пока зависшие висели.

Дедушка
и что происходит с tempdb в это время?

Как это посмотреть?
7 июн 18, 16:56    [21476818]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить