fed: Parallel BOM calculation in RollUp 7

[Blog bot]

Источник: http://fedotenko.info/?p=193
==============

Since Microsoft released most recent update of Dynamics AX (I mean SP1 rollup 7), I would like to point the readers of my blog to very important update in this version, which can dramatically increase performance of one of the critical, but slow operations from production module of Axapta.

I am talking about BOM Calculation process, which in previous version can only be started in single-thread mode. I heard about implementations, where BOM recalculation for all BOMs in the system were taking more then 2 days.

Somewhere in the last December, Microsoft released hotfix KB2487033, which supported multi-threaded execution of BOM calculation and now this feature included into RollUp7.

This nice feature works only if BOM Calculation is started not for a given ItemId, but for  all BOMs in the system (say – from costing version form) and if user specified batch-mode calculation of this batch job. In this case, the system behaves the following way:

1. BOM levels are recalculated
2. Tables bomCalcItemTask and bomCalcItemInventoryDimensionTask  are populated with item ids and item inventory dimensions to calculate. (These two steps are also executed in standalone, single-threaded mode of calculation).
3. In single-threaded mode, the system starts to iterate over the items to calculate, starting from the lowest level components (with numerically highest BOM Level).
4. In multi-threaded mode, system SPAWNS a certain number of helper tasks for EVERY BOM level to be calculated. It also set dependencies between tasks of every BOM Level, so jobs of BOM Level 7 starts only after tasks of BOM Levels 8 and 9 are completed, tasks of BOM Level 5 depends on tasks of BOM levels 9,8,7,6
5. Then in multi-threaded mode, system just calculates every BOM level in parallel. It is quite meditative experience - to look onto progress of tasks in you BOM Calculation Batch job.  It also saves you a lot of time. In my case, calculation time dropped from one night to something like 20-30 minutes and 10 minutes of it, were taken for BOM Level recalculation (I guess, it is principally not parallelizable task by itself).

Nevertheless, there are a few issues, which I would like to share here:

1. The BOM Calculation process is not robust. If one of the BOMs has an error (quite typical if data were imported from heritage system), then on the first error, one of the BOM recalculation tasks will terminate. Then next task will try to recalculate the same BOM and terminate again, then next, and so on. As a result, usually, after first calculation I will find out that only 20-30 percent of you items has new prices. Solution for the issue is simple: You should simply put try {} except block somewhere inside  BOMCalcJob_All.runBOMCalculation() method, so error in BOM would not terminate the whole job.
2. When system calculates the number of helper threads, which will be used for BOM Calculation, it is implicitly assumes, that all available batch servers will be used for the calculation. If you have 3 batch servers and every server has 8 maximum batch threads specified in batch server configuration, the system will spawn 24 helper threads for every BOM level. First of all, the number itself is too big, normally 8-12 threads should be enough. Morever, if you going to use only one batch server (out of three) for given BOM Calculation, these 24 helper threads will be executed in three steps (8 threads each). So, I recommend to modify BomCalcJobItemTaskBatchManager.numberOfBatchSessions() method to return more reasonable number of threads if you have more then 1 batch server or if your batch server has too many batch threads.

Also, as kind of shameless self-promotion , I want to mention that for one of my project I made a clone of the feature, but the clone, which calculates in parallel only ONE BOM with all dependent sum-BOMs and items.







Источник: http://fedotenko.info/?p=193

[Ievgenii]

Цитата:

dramatically increase performance of one of the critical, but slow operations from production module of Axapta

Спасибо FEDу за положительный отзыв от всех разработчиков логистики :0)

[fed]

Вам спасибо! На одном из моих проектов (правда я там только приглашенный консультант), данная фича разрешила тяжелую политическую ситуацию по поводу производительности системы.

[Logger]

Цитата:

Сообщение от Ievgenii

Спасибо FEDу за положительный отзыв от всех разработчиков логистики :0)

Похоже, распараллеливание становится популярным способом решения проблем производительности. И это радует.

Вы случаем не планируете распараллелить разноску накладных и журналов ? Или хотя бы убрать квадратичные зависимости от числа строк при расчете налогов ?

[fed]

Задача разноски журналов (не складских) в целом уже решена (правда не самым симпатичным образом). Если у тебя большие журналы, проставляешь поле Lines Limit в шапке журнала в, скажем, 500 строк. Потом запускаешь В ПАКЕТНОМ РЕЖИМЕ разноску выбранных журналов из Главная книга->Периодические операции->Разнести журналы (у меня нету русской версии под рукой, могу ошибаться в названии пункта меню). Система аккуратно разрезает твои журналы на несколько штук, по 500 строк в каждой, а потом их всех в параллельном режиме разносит.

Не очень удобно, конечно, с точки зрения возможности дальнейшей работы с разнесенными журналами, но жить можно.

С накладными тоже достаточно похоже: Если ты запускаешь разноску МНОЖЕСТВА накладных по многим заказам/закупкам (через Summary Update) в пакетном режиме, то каждая накладная будет создаваться в отдельном пакетном задании. Правда, если у тебя всего одна накладная, но большая - то тебе это никак не поможет. Но с другой стороны - накладные по 2000 строк каждый день и не разносятся

[Logger]

Да, я имел в виду случай когда одна накладная с числом строк 500 и более тысячи.

[fed]

Цитата:

Сообщение от Logger

Да, я имел в виду случай когда одна накладная с числом строк 500 и более тысячи.

Там, как я понимаю, главная проблема - обеспечение целостности данных. Не трудно подправить класс разноски таким образом, чтобы на разноску строк порождалось n-задач. Проблема в том, что случиться если у тебя в заголовке накладной будет одна сумма, а часть задач по разноске строк почему-то не смогла отработать, и строк накладной не образовалось.
Можно конечно запускать задачи разноски строк ДО всего остального и все остальное запускать только если строки успешно разнеслись, но тогда у тебя в системе какое-то время будет накладная со строками, но без шапки
P.S. Ну и конечно начинать транзакцию в одной задаче,а заканчивать в другой - нельзя по определению.

[Logger]

Эти проблемы понятны.
Но они решаемы.
Сделали же закрытие склада с нескольких клиентов. Тут все аналогично.

[fed]

Цитата:

Сообщение от Logger

Эти проблемы понятны.
Но они решаемы.
Сделали же закрытие склада с нескольких клиентов. Тут все аналогично.

Неа - аналогично не получиться. В закрытии изначально были разделены сопоставления и разноска в ГК. Поэтому их разделили легко. А для того чтобы отделить разноску списания (например) от создания строки накладной или изменения статуса складских проводок - придется всю идеологию разноски накладной покурочить. Кроме того, надо понимать что закрытие склада случается раз в месяц и контроллирует его либо айтишник, либо кто-то из ключевых сотрудников бухгалтерии. Соответственно - если что-то пошло не так, то скорее всего это заметят и как-то починят. Наконец - закрытие склада, сломавшееся на полпути, можно безнаказанно отменить и повторить еще раз. А накладные оформляют низовые сотрудники причем десятками и сотнями в день. Если парочка накладных как-то некорректно разнеслась, то заметят это не сразу. Наконец - без написания кучи джобов, порушившуюся накладную не удалить будет...

Я думаю, если они в новой версии сделали исполнение кода на clr-runtime, есть шансы что там задача решается с помощью нескольких нитей в рамках одной транзакции. Однако почитав про те грабли, которые порождает использование clr-runtime, я как-то засомневался, нужно ли мне ускорение разноски за такую цену...

[Logger]

Ну если не распараллеливание, то какие другие способы ускорения разноски больших журналов и накладных вы видите ?

Выше вы предполагали что это не нужно или нужно редко. Т.е. ничего не предложили. А если нужно и достаточно часто, то что можно предложить ?

Как вариант, можно вместо одной накладной на 1000 строк обработать 25 по 40 строк и объединить в один документ при печати. (Хотя это просто другой способ распараллеливания)

Другие варианты пока в голову не приходят.

[Ievgenii]

Цитата:

Вы случаем не планируете распараллелить разноску накладных и журналов ? Или хотя бы убрать квадратичные зависимости от числа строк при расчете налогов ?

Посмотрите на Dynamics Ax 2012. Там постинг sales\purchase ордеров вроде так и реализован. Про складские журналы - такая задача была и есть но руки до нее пока не дошли либо надо менять весь Journal Framework а это не недельная задача

Цитата:

Ну если не распараллеливание, то какие другие способы ускорения разноски больших журналов и накладных вы видите ?

IL - насколько я знаю в Dynamics Ax 2012 постинг тех же purchase orders на 40% быстрее чем в Ax2009 только благодаря выполнению кода в IL
.

[Logger]

Цитата:

Сообщение от Ievgenii

Посмотрите на Dynamics Ax 2012. Там постинг sales\purchase ордеров вроде так и реализован. Про складские журналы - такая задача была и есть но руки до нее пока не дошли либо надо менять весь Journal Framework а это не недельная задача

IL - насколько я знаю в Dynamics Ax 2012 постинг тех же purchase orders на 40% быстрее чем в Ax2009 только благодаря выполнению кода в IL
.

Спасибо за ответы. Обязательно посмотрю.

[fed]

Цитата:

Сообщение от Logger

Ну если не распараллеливание, то какие другие способы ускорения разноски больших журналов и накладных вы видите ?

Выше вы предполагали что это не нужно или нужно редко. Т.е. ничего не предложили. А если нужно и достаточно часто, то что можно предложить ?

Для закупок, я бы пошел таким путем:
1. При разноске накладной по закупке, вместо обновления складских проводок и разноски на складские счета, делается проводка ГК на некий субсчет 15ого счета
2. После разноски накладной, порождается пакетное задание на параллельное обновление складских проводок с разноской в ГК. Код разноски правиться так, чтобы в качестве коррсчета прихода использовался субсчет 15ого счета.
3. Если пакетное задание некорректно завершилось, посылается alert кому надо
4. Надо бы еще подумать на тему усиленной проверки строк накладных в момент 1ого пункта, чтобы снизить вероятность когда накладную мы разнесли, а потом выяснилось что на склад не может оприходовать, потому что, скажем, финансовая аналитика не указана. (которая только на 10ке нужна, а на 15ом - нет).

Для заказов можно аналогичную схему использовать,но только если комплектация используется и к моменту разноски накладных и отборочных, товар уже собран и точно физически присутствует в системе. Просто в случае списания, некоторое отставание в состянии inventSum само по себе критично, а уж если сначала накладную распечатали и отдали, а потом выяснили что такого товара нету - так вообще кранты...

[Ivanhoe]

Цитата:

Сообщение от Logger

Ну если не распараллеливание, то какие другие способы ускорения разноски больших журналов и накладных вы видите ?

Большие заказы характерны, например, в ритейле, когда нужно сделать разноску реализации магазина за день. В плане оптимизации разноски можно многое поправить, в т.ч. в коде отключить все неиспользуемые функции. В т.ч. можно рассмотреть вариант SQL-й разноски - есть прецеденты Но все это - тюнинг под конкретный проект, в глобальное решение такое не включат и всегда будет запас под точечную оптимизацию.

[Logger]

Ну почему не включат ?
Делают же оптимизации тяжелых операций.
Закрытие склада, спецификации, блокировки по InventSum и.т.п.

Да мало ли где нужна разноска таких заказов.
ЕРП система за кучу денег должна это делать без проблем.

[Logger]

Цитата:

Сообщение от fed

Для закупок, я бы пошел таким путем:

Спасибо.
Для заказов мы как раз юзаем комплектацию. Так что хорошо ложится на нашу схему.

[fed]

Цитата:

Сообщение от Logger

Спасибо.
Для заказов мы как раз юзаем комплектацию. Так что хорошо ложится на нашу схему.

А вы не пробовали профилироваться и смотреть на что время тратиться в основном ? Просто такие тормоза были характерны для времен до изобретения InventSumDelta/InventSumDeltaDim. Может у вас там какие-то доработки не удачные или добавили условие в select, а индекс забыли ?
Даже как-то интересно стало

[Logger]

Проблемы у нас как правило на закупках лезли. Профилироваться пробовал.
Основное время уходит на расчет налогов. С ростом числа строк в накладной время расчета нелинейно растет.

Т.е. если накладная из 100 строк обрабатывается 30 секунд, то накладная из 1000 строк будет обрабатываться не 300 или менее секунд (как можно было бы ожидать из-за снижения удельного веса накладных расходов) а непропорционально дольше.

Блокировки ни при чем, так как проверку делали в отдельной тестовой компании, в рабочей базе.
Тест проводили на 3-ке SP5. В 2009-й судя по поведению ничего не изменилось. Детально это все пофиксить пока руки не дойдут. Пока придумали заглушку - в виде разбиения на кучу накладных по 40 строк. Нормально работает. Т.е. получается что быстрее обрабатывается 25 накладных по 40 строк чем одна большая на 1000.

В этом мне видится основная проблема. Так как число строк в документе - это случайная величина с матожиданием в районе 50-100 строк. Большинство документов проходит нормально, но несколько раз в день (а к сожалению не только в день, но и в ночь, так как работаем 24/7) случаются всплески, когда попадаются большие документы и на них все подвисает.

[Logger]

Ну вот я и подумал, что чем лечить нелинейные зависимости времени обработки в коде, рискуя накосячить в налогах и вообще все нахрен поломав, то не проще ли применить общий подход по параллельной обработке. Т.е. если бы эти 25 накладных в моем случае обрабатывались бы параллельно, а потом в конце агрегировались в один документ (если номер накладной и ваучер одинаковые, то это получалось бы почти автоматически) то мы бы получили многократное увеличение скорости обработки документов (в 40 раз для документа из 1000 строк, конечно при условии что есть достаточно вычислительных мощностей на аосе).

Самое главное в таком подходе - что он легко масштабируется с ростом числа строчек ! И у нас не простаивают процессорные ядра на серверах.

А перевести на выполнению кода в IL - это конечно ускорение, но принципиально дела не меняет, так как характер зависимости времени обработки от числа строк остается тем же самым (предположительно квадратичным)
Так что если число строк в документе вырастет не до 1000 а, например, до 5000 - то мы получим те же самые проблемы даже с выполнением кода в IL

[Logger]

О!
По поводу налогов было уже обсуждение нелинейной зависимости времени расчета от числа строк в документе:
Оптимизация класса Tax