AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 04.08.2021, 00:12   #1  
alicedr is offline
alicedr
Участник
 
157 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Киев
deadlock в кастомном батч джобе
D365FO 10.0.20
Есть кастомный джоб на SysOperationsFramework, задача которого создать запись в таблице, выполнить запрос к внешнему ресурсу и проапдейтить запись с результатом запроса.

Выполняется все это дело по нескольким компаниям одновременно, а коткретно сразу в 6-8 компаниях и с 8 потоками в каждой компании.

В половине потоков наблюдаются дедлоки, жертвами являются практически все запросы на обновление (update) основной таблицы с транзакциями.

Все дедлоки наблюдаются в праймари индексе таблицы. Он уникальный и кластерный. Есть несколько других индексов, но они не уникальные и в дедлоках не светятся.

ВОПРОС: как решить вопрос с дедлоками? Как временное решение, праймари индекс был изменен на не-кластерный, пока тестируем.

Судя по наличию дедлока, в некоторых случаях сначала блокируется таблица, а потом индекс, а в других апдейтах сначала индекс а потом таблица.
Как определелить какой будет порядок блокирования по коду в X++?

Если же они блокируются в одинаковом порядке, то дедлоков по идее быть не должно, должны быть ожидания...
Старый 04.08.2021, 19:29   #2  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,532 / 2472 (90) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Вы наверно создаете сперва запись пустышку, а затем обновляете ее, возможно сильно увеличив размер записи.
Может у вас при обновлении страничка расщепляется в таблице. Попробуйте обойтись без обновления, только вставкой.
Старый 04.08.2021, 19:33   #3  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,590 / 1757 (66) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от alicedr Посмотреть сообщение
Выполняется все это дело по нескольким компаниям одновременно, а коткретно сразу в 6-8 компаниях и с 8 потоками в каждой компании
..
ВОПРОС: как решить вопрос с дедлоками?
Мысль #1: не зарываясь в детали (которых все равно в Вашем сообщении крайне мало чтобы пробовать чинить такое "по фотографии") - а не хотите сериализовать запуски этих джобов в рамках одной компании, поместив их тасками в один джоб вместо параллельных джобов?
Мысль #2: если такой сетап выбран осознанно и обработка неизбежных дедлоков реализована корректно - в чем проблема?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 04.08.2021, 22:54   #4  
alicedr is offline
alicedr
Участник
 
157 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Киев
Logger: Спасибо за идею, у меня тоже была такая, но, к сожалению, реализовать такое невозможно в данном случае.
Старый 04.08.2021, 23:00   #5  
alicedr is offline
alicedr
Участник
 
157 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Киев
Цитата:
Сообщение от Vadik Посмотреть сообщение
Мысль #1: не зарываясь в детали (которых все равно в Вашем сообщении крайне мало чтобы пробовать чинить такое "по фотографии") - а не хотите сериализовать запуски этих джобов в рамках одной компании, поместив их тасками в один джоб вместо параллельных джобов?
Мысль #2: если такой сетап выбран осознанно и обработка неизбежных дедлоков реализована корректно - в чем проблема?
#1: это требование клиента, которого предупреждали о возможности дедлоков.
#2: обработка проведена корректно, но наличие дедлоков, особенно на продакшене, недопустимо так как сильно влияет на производительность всей БД. Не совсем понятно, почему возникают именно дедлоки, а не события ожидания, т.к. порядок вызова и, следовательно, блокирования обьектов БД одинаковый.
Старый 04.08.2021, 23:28   #6  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
347 / 379 (13) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от alicedr Посмотреть сообщение
Logger: Спасибо за идею, у меня тоже была такая, но, к сожалению, реализовать такое невозможно в данном случае.
А почему невозможно-то?

В крайнем случае сделайте две идентичных таблицы, А и Б. Запись-пустышку пишите в А и отправляйте запрос во внешнюю систему. После получения ответа вставляйте полную запись в Б и удаляйте старую запись из А одной транзакцией. Если нужно видеть все записи в одном гриде, сделайте вьюху типа Union.

Другой вариант - при апдейтах каждому из восьми процессов назначить свой диапазон обработки. Скажем, если первое поле в первичном ключе содержит ItemId, и все ItemId в системе начинаются с цифры, то первому процессу назначить «0*», второму «1*» или «1*, 2*» и т.д.
Старый 06.08.2021, 09:00   #7  
trud is offline
trud
Участник
Лучший по профессии 2017
 
999 / 1475 (51) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
А разве deadlock возможен на OCC enabled таблице? вы случайно не используйте update_recordset где-нибудь в коде?
Старый 06.08.2021, 21:45   #8  
alicedr is offline
alicedr
Участник
 
157 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Киев
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
А почему невозможно-то?

После получения ответа вставляйте полную запись в Б и удаляйте старую запись из А одной транзакцией.
.
При таком количестве потоков удаление будет провоцировать новые дедлоки. Но сама идея очень хорошая и у меня уже есть идеи где ее использовать )))

На самом деле проблема уже решена - мое предположение заменить кластерный индекс на некластерный сработало - за три дня не было ни одного дедлока при постоянном очень интенсивном тестинге.
За это сообщение автора поблагодарили: Vadik (1).
Старый 08.08.2021, 13:39   #9  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,590 / 1757 (66) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от alicedr Посмотреть сообщение
На самом деле проблема уже решена - мое предположение заменить кластерный индекс на некластерный сработало
Кластерный индекс был составной или состоял из одного поля? RecId, Guid, номерная серия в FO, еще что-то ? Если составной, были ли при обработке изменения в ключевых полях ?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 09.08.2021, 15:53   #10  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
125 / 292 (10) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от Logger Посмотреть сообщение
Вы наверно создаете сперва запись пустышку, а затем обновляете ее, .... Попробуйте обойтись без обновления, только вставкой.
Поддерживаю. Кроме предложенного тут варианта использования второй таблицы. Можно еще сделать мапу из буферов в памяти. И хранить все не в таблице, а в памяти. Потом оттуда (из памяти) вставлять в таблицу.

Лучше избегать лишних операций с SQL.
Старый 09.08.2021, 20:56   #11  
alicedr is offline
alicedr
Участник
 
157 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Киев
Цитата:
Сообщение от Vadik Посмотреть сообщение
Кластерный индекс был составной или состоял из одного поля? RecId, Guid, номерная серия в FO, еще что-то ? Если составной, были ли при обработке изменения в ключевых полях ?
Одно поле. transId. Никакх изменений, кроме clustered -> non-clustered
Теги
d365fo, deadlock

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
ODBCConnection и обработка deadlock abark DAX: Программирование 7 12.02.2016 13:37
dynamicsaxtraining: What is Lock, Deadlock in Dynamics AX Blog bot DAX Blogs 0 02.06.2015 13:11
DeadLock. Один сеанс - несколько процессов. Владимир Максимов DAX: Программирование 20 12.07.2008 11:02
Пример DeadLock Maxim Gorbunov DAX: База знаний и проекты 0 06.12.2001 20:00
DeadLock Maxim Gorbunov DAX: База знаний и проекты 0 03.12.2001 20:16
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:40.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.