|
Deadlock
|
|||
---|---|---|---|
#18+
FB 2.5.6. Сегодня во время работы база зависла, а спустя некоторое время стали выдаваться сообщения: Код: plaintext 1.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Вопрос - что-то с обработкой Deadlock'ов случилось? Вроде же FB должен разруливать такие ситуации в штатном режиме. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2017, 04:01 |
|
Deadlock
|
|||
---|---|---|---|
#18+
CyberMax, Именно "Deadlock." и ничего больше? За 2.5 я уже ничего не знаю, но раньше deadlock поминался всуе при некоторых других ошибках, причём сначала поминался именно он, а реальная ошибка после него. Что точно помню - при неверном логине/пароле при присоединении, но и ещё что-то было. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2017, 22:11 |
|
Deadlock
|
|||
---|---|---|---|
#18+
В это воскресенье ситуация повторилась. Удалил из таблиц в общей сложности больше двухсот миллионов строк (это происходило почти полтора часа, в это время другие пользователи добавили туда несколько строк), делаю коммит - и все, deadlock с периодическим выбросом у всех пользователей этого исключения. Попытался подключился fb_lock_print'ом к базе - он завис. Помогла остановка процесса сервера, которая на сей раз отработала мгновенно. Что самое интересное, SELECT после этого выдал только несколько десятков добавленных строк. То есть де-факто коммит произошел. Я могу попробовать воспроизвести такой deadlock в ближайшее время, но не знаю, имеет ли это смысл и что дальше с этим делать. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2017, 09:53 |
|
Deadlock
|
|||
---|---|---|---|
#18+
CyberMaxВ это воскресенье ситуация повторилась. Удалил из таблиц в общей сложности больше двухсот миллионов строк ... и что дальше с этим делать. Дедлок это конечно не хорошо, но чисто из практики я бы не делал таких больших удалений за один раз. Если требуется, я удаляю максимум по 50-100 тысяч записей, коммит, и потом селект с теми же параметрами что и delete - сразу соберем за собой мусор. И поведение получается гораздо предсказуемее. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2017, 10:42 |
|
Deadlock
|
|||
---|---|---|---|
#18+
ты когда такие массированные удаления делаешь, индексы отключай. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2017, 12:19 |
|
Deadlock
|
|||
---|---|---|---|
#18+
если воспроизводить - то наверное на 2.5.7 а не 2.5.6 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 15:04 |
|
Deadlock
|
|||
---|---|---|---|
#18+
Сегодня очищал одну таблицу с миллионом записей, которую никто не использовал. Во время удаления случился deadlock на некоторых рабочих станциях. Здесь ситуация стала понятной. Дело в том, что программа один раз в пять минут обращается к серверу за новостями. Делается это в запущенной при подключении RO-транзакции. Исключение: Код: plaintext 1. 2.
Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Поэтому в первом посте сообщение про Deadlock выдавалось периодически - по таймеру шло обращение к серверу, при подготовке возбуждалось исключение, а так как обращений к БД в событии было несколько, то они и генерировали эти исключения подряд. Сегодня это удаление завершилось без проблем, и рабочие станции продолжили работу в нормальном режиме. Итого получается, что во время удаления (или коммита удаления) что-то блокирует подготовку запроса. Вопрос к разработчикам: действительно ли в коде FB при подготовке выполняются какие-то действия, которые могут приводить к дедлоку? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2017, 05:13 |
|
Deadlock
|
|||
---|---|---|---|
#18+
CyberMax, теоретически может такое быть. Недавно исправлялся один похожий баг , там более специфический сценарий, но внешние симптомы аналогичные. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2017, 10:04 |
|
|
start [/forum/topic.php?fid=40&msg=39486337&tid=1561475]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
129ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 294ms |
total: | 504ms |
0 / 0 |