|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Добрый день. На сервере произошёл сбой, при ручной проверке запрос sp_WhoIsActive показало, что проблема в двух сессиях заблокировавших друг друга. Вроде простой дедлок, но они так висели 10+ минут, пока я не убил одну из сессий. При этом запрос по sys.sysprocesses показывал, что одна из сессий участников дедлока не заблокирована, а ждёт один из потоков параллелизма (CXPACKET). Было похоже, на то что сервер по какой-то причине не смог опознать дедлок. Но настроен сбор сведений о дедлоках в Extended Events и там были события с этими двумя сессиями. При этом куча одинаковых событий на протяжении 10+ минут с пометкой одной из сессий как victim, но реально сессия убита не была. Во вложении пример схемы события, как victim был выбран запрос параллелизмом. С чем может быть связано то, что SQL Server не смог убить участника дедлока и блокировки продолжались до вмешательства человека? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 09:50 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Сессия одна. У вас дедлоки внутри одного запроса с параллелизмом. Поэтому убивать нечего. Лечение "в лоб" - выставить для запроса maxdop 1 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 10:08 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
invm, Там дедлок между двумя запросами. На один скриншот всё не влезло с нормальным масштабом и оставил все по 329 сессии. Добавляю правый кусок схемы, там ресурс и вторая сессия. Фиг, что-то не добавляет ещё скриншот. Правее от первого скрина ещё есть key lock по РК, ниже Page lock и правее вторая сессия участник дедлока. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 10:17 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion, Можно ещё попробовать проанализировать, на чём возникает кривое распределение по потокам и попробовать привести данные к более параллелизуемому виду. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 10:18 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Попытка добавить общий скрин, но плохое качество деталей. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 10:24 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion Фиг, что-то не добавляет ещё скриншот. Правее от первого скрина ещё есть key lock по РК, ниже Page lock и правее вторая сессия участник дедлока. так не лепите граф картинкой, приведите текстом, можно в спойлере ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 11:03 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Yasha123, На схему вроде удобно смотреть для наглядности и её удалось выложить. В тексте много имён серверов, баз данных, таблиц и прочей информации, которую я бы предпочёл не указывать. Что никто не сталкивался с подобным? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 11:59 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion, Сталкивались , конечно. И даже одно из решений первым же ответом дали. Дедлоки на exchange event при ожиданиях cxpacket явно показывают, что проблема с распределением данных в потоках. Либо убивайте параллелизм, либо ищите как выровнять распределение (от банального on t1.id = t2.id + 0 , до ручных статистик и предварительных сортировок) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 12:33 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
env, Хм, по ссылке вроде блокировка с участием одной сессии - внутри потоков одного запроса. У меня же две разные сессии. Там же: Just because you see “exchangeEvent” resources in your deadlock graph doesn’t necessarily mean that you are facing an intra-query parallelism deadlock. Sometimes the engine includes extraneous resources in the deadlock graph. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 12:45 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion, Отловите "в моменте" и убедитесь, что это не сессии координатора и слейва. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 12:54 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
env, Да, если будет повторяться, то убрать параллелизм действительно вариант. При это по информации от разработчиков данный запрос выполняется уже несколько лет. Но это без уточнения плана запроса, может всё время и шло без параллелизма. Пока случай одиночный. Тут скорее интересует почему вообще такое может происходить. <victim-list> <victimProcess id="processbb3c067848" /> </victim-list> <process id="processbb3c067848" taskpriority="0" logused="10000" waittime="396" schedulerid="10" kpid="18308" status="suspended" spid="329" sbid="1" ecid="4" priority="0" trancount="0" lastbatchstarted="2020-11-17T08:18:34.760" lastbatchcompleted="2020-11-17T08:18:34.710" lastattention="1900-01-01T00:00:00.710" hostname="Priklad" hostpid="0" isolationlevel="read committed (2)" xactid="54905556086" currentdb="9" currentdbname="DataBase" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> Часть информации по жертве, ecid 4 что совпадает со схемой. Дальше в xml идут process id остальных 4 потоков и сессия 428, но в victim-list они не входят. А SQL Server вообще может пытаться убить не всю сессию 329, а конкретный поток? Мне казалось, что нет, но пока в данной ситуации похоже именно на такую попытку. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 13:25 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion env, А SQL Server вообще может пытаться убить не всю сессию 329, а конкретный поток? Мне казалось, что нет, но пока в данной ситуации похоже именно на такую попытку. вы вообще о чем? система разрешения взаимоблокировок не убивает сессию. она отменяет транзакцию сессии, потоки здесь вообще не причем. взаимоблокировки связанные с параллелизмом в принципе известны (можете погуглить что то типа intra-query deadlock). Поскольку механизм разрешения взаимоблокировок не реагирует именно на ситуации в параллельными взаимоблокировками решаются такие проблемы обычно анализом "а нужен ли вообще в том запросе параллелизм" и снижением степени для его возникновения. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 02:08 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
felix_ff, Так почему тут есть события дедлока(куча одинаковых в эти минуты), где сессия помечена как жертва. А отмена транзакции не произошла? В данной ситуации основная проблема не в том, что вообще произошёл дедлок (это печально, но бывает), а в том, что SQL Server не смог сам убрать одну из сессий участников. Когда руками была убрана вторая сессия, то 329 с параллелизмом спокойно завершилась. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 13:40 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion, вы граф дедлока полностью покажете наконец или будете кормить нас крупицами инфы из него? прикрепите полный граф в xml формате. если у вас была взаимоблокировка intra-query parallel thread то сиквел сам такие взаимоблокировки не разрешает. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 13:45 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
felix_ff, Ок, заменил имя БД, таблиц и сервера на аналог, остальное не трогал. Код: xml 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. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 14:14 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
invm У вас дедлоки внутри одного запроса с параллелизмом. +1 Danion, покажите select @@version с сервера priklad-05 должен был выиграть этот дедлок и пойти дальше забавная параметризация у запроса (сессия 428) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 15:05 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion, У вас не self-deadlock, а банальный дедлок читателя с писателем из-за разного порядка блокировок строк/страниц. И если запрос-жертва продолжает выполняться, значит физически жертвой стал один из потоков параллельного запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 15:11 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
invm, Версия: Microsoft SQL Server 2017 (RTM-CU21) (KB4557397) - 14.0.3335.7 (X64) Jun 12 2020 20:39:00 Copyright (C) 2017 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: ) (Hypervisor) Параметризацию коллеги из разработки осваивают, пока бывает странное. Там действительно для id напрашивается. "У вас не self-deadlock, а банальный дедлок читателя с писателем из-за разного порядка блокировок строк/страниц. И если запрос-жертва продолжает выполняться, значит физически жертвой стал один из потоков параллельного запроса." Вот мне и кажется, что дедлок между двумя разными запросами, но мне пишут, что дедлок внутри запроса с параллелизмом. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 15:21 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion остальное не трогал. Да, разные сессии. Проверяйте статистику и планы запросов. Скорее всего пересекаетесь на рандомных seek и последовательном scan. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 15:46 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion, по сути у вас такая, ситуация. сейчас попробую у себя поиграться. не помню точно должна ли вообще такая взаимоблокировка разруливаться системой если жертвой выступает не поток координатора. транзакция то на сессии с параллелизмом одна и таже. блин как прикрепленную картинку в спойлер пихнуть? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 15:49 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Несколько раз уже повторялись подобные ситуации. Проблема в том, что сам сервер вообще не может справиться с ситуацией. Часами висят блокировки в две сессии с дедлоками, особенно плохо, если такое происходит во вне рабочее время. В extended events видно, что сервер пытается убить одну из сессий, хотя больше похоже на попытку убить один из потоков сессии с параллелизмом и не может. При этом человек через kill session_id спокойно убирает проблему. Есть какие-то варианты помочь серверу самому справляться с такими дедлоками? Убирать параллелизм для всего сервера не вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2021, 16:42 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Варианты 1. Таки обновить сервер последним апдейтом. 2. Таки убрать параллелизм с ЭТОГО запроса, если всегда один и тот же запрос. 3. Таки выставить SET LOCK_TIMEOUT nnnn; для этого запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2021, 17:45 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
aleks222, 2017 CU24 сейчас. Пару раз уже обновляли с CU с момента первой встречи подобной ситуации на системе, но улучшений нет. Да и в списке исправлений там похожего не видел. Запросы разные. Встреченные переделывали, ситуация была не очень часто, а на этой неделе уже второй раз такое. Вот и интересуют варианты для устранения ситуаций в будущем с похожими симптомами, но разными запросами. Сейчас на сервере нет дополнительных приспособлений для убийства долго выполняющихся сессий\блокировок, но если будет часто повторяться, то придётся что-то придумывать и добавлять. При этом по не видно что там дедлок sys.sysprocesses, одну из сессий показывает, что просто в CXPACKET ждёт, дополнительный мониторинг тоже не очень этот момент показывает. Виден дедлок через extended events и руками через sp_WhoIsActive. Обычно не используем автокилы, чтобы случайно чего лишнего не убрало, в данной ситуации ещё и определять в автоматическом режиме сложнее, половина способов не видит, что это дедлок и сервер уже встал в тысячах блокировок. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2021, 18:32 |
|
При deadlock не прошло автоматическое снятие сессии
|
|||
---|---|---|---|
#18+
Danion, Не вы один с такой проблемой - https://docs.microsoft.com/en-us/answers/questions/375485/unhandled-deadlocks-with-sql-server-2017.html 1. Если можно менять запросы, попробуйте в select для table1 указать rowlock. 2. Менять maxdop для всего сервера не требуется. Можно указать для запроса option (maxdop 1). Или через plan guide - https://docs.microsoft.com/en-us/sql/relational-databases/performance/plan-guides?view=sql-server-ver15 Даже без параллелизма ситуация все равно потенциально дедлочная: у читателя гранулярность блокировок - страница, а у писателя - строка. И желательно все-таки увидеть актуальный план select'а ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2021, 19:00 |
|
|
start [/forum/topic.php?fid=46&msg=40092522&tid=1684385]: |
0ms |
get settings: |
11ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
131ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 285ms |
total: | 519ms |
0 / 0 |