Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Спонтанная просадка производительности
|
|||
|---|---|---|---|
|
#18+
Привет всем! Есть хранимая процедура, в ней около 75 statement'ов. Запускается она одновременно из разных клиентов (ASP.NET). Почти всегда отрабатывает быстро, но иногда зависает на десятки минут. Параметры, с которыми она была вызвана при зависании, мне известны. Увы, при вызове из SSMS с теми же параметрами все опять работает быстро, так что дело не в параметрах. В кеше планов лежит ровно один элемент по этой процедуре, так что тут дело и не в том, что соединения SSMS и ASP.NET имеют разные свойства и выполняют одно и то же по разным планам. Запускаю вот такую диагностику и вижу несколько сеансов, выполняющих эту процедуру и застрявших на одном и том же statement'е, который вставляет данные во временную таблицу. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Далее, я посмотрел на 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: ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2018, 11:37 |
|
||
|
Спонтанная просадка производительности
|
|||
|---|---|---|---|
|
#18+
SergASh, авторСам план вроде бы нормальный это да.... dm_exec_requests - blocking_session_id скорее всего не ноль, вот все и ждет пока разойдутся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2018, 11:55 |
|
||
|
Спонтанная просадка производительности
|
|||
|---|---|---|---|
|
#18+
TaPaK, blocking_session_id ноль во всех зависших сессиях ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2018, 12:51 |
|
||
|
Спонтанная просадка производительности
|
|||
|---|---|---|---|
|
#18+
SergAShПараметры, с которыми она была вызвана при зависании, мне известны. Увы, при вызове из SSMS с теми же параметрами все опять работает быстро, так что дело не в параметрах.из SSMS вызывали сразу же или "на следующий день"? SergAShи вижу несколько сеансов, выполняющих эту процедуру и застрявших на одном и том же statement'е, который вставляет данные во временную таблицу.и что происходит с tempdb в это время? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2018, 13:34 |
|
||
|
Спонтанная просадка производительности
|
|||
|---|---|---|---|
|
#18+
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 тормозит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2018, 13:50 |
|
||
|
Спонтанная просадка производительности
|
|||
|---|---|---|---|
|
#18+
по традиции :)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? Я уже не спрашиваю за обслуживание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2018, 14:14 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39657358&tid=1689611]: |
0ms |
get settings: |
10ms |
get forum list: |
28ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
142ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 265ms |
| total: | 527ms |

| 0 / 0 |
