Параллельная разноска журналов ГК DAX 2012. Реально ли?

Хочется разносить параллельно много много журналов. Возникает вопрос делал ли кто такое? Подводные камни есть?. Приветствуются мысли и соображения.
Буду рад узнать.

[gl00mie]

А в чем подвох? Выделите на форме шапок журналов сразу штук хрендцать и запустите разноску в пакете - она сама распараллелится, это стандартный функционал в AX 2012. Для оптимизации разноски журналы пакуются в "пакеты" (bundles) примерно по 1000 строк суммарно, на каждый "пакет" создается отдельная пакетная задача разноски.

См. также Post multiple journals [AX 2012]

А нет подвоха. Есть утверждение некоторых коллег что при попытке распараллелить получили какие-то проблемы и хочется понять насколько реальны эти проблемы.

[DSPIC]

См. также https://technet.microsoft.com/en-us/.../dn527213.aspx

Давайте на все подряд кидать ссылки?
Вопрос вроде поставлен четко требуется распараллеливание разноски множества журналов ГК - будут ли проблемы? Опыт?
Пока ничего конкретного не увидел по ссылкам
Если не сложно разверните пожалуйста связь между ссылками и вопросами.
Если резко выразился извините но для меня ключевое слово распараллеливание, с целью достичь мега скорости при разноске десятков тысяч жкрналов ГК.

[russ]

Если к примеру необходимо разносить амортизацию Основных средств, то проблемы могут быть при неправильной разбивке ОС в разрезе журналов. Амортизация для одного конкретного ОС должна разносится последовательно по дате: сначала за январь, потом февраль и т.д. Если амортизация за январь находится в одном журнале, февраль в другом, при попытке разноски журналов в параллели, получим ошибку в февральском журнале. Такова специфика разноски журналов Основных средств. В других модулях своя специфика, свои проверки.

[Михаил Андреев]

Ещё одна специфика - на сколько строк разбивать журнал при разноске. Методики точного расчёта данной цифры я не встречал, действовали "методом тыка". По опыту было от 200 до пары тысяч (разносили журналы из примерно 100 тыс строк: 53 тыс ОС * 2 модели учёта и смотрели на время разноски всех журналов).

[gl00mie]

Цитата:

Сообщение от Михаил Андреев

Ещё одна специфика - на сколько строк разбивать журнал при разноске. Методики точного расчёта данной цифры я не встречал, действовали "методом тыка". По опыту было от 200 до пары тысяч (разносили журналы из примерно 100 тыс строк: 53 тыс ОС * 2 модели учёта и смотрели на время разноски всех журналов).

В стандартный код распараллеливания разноски журналов ГК зашита константа в 1000 строк (ограничение на размер bundle'а с одним или несколькими журналами), думаю, это - достаточно хороший ориентир.

Цитата:

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

В стандартный код распараллеливания разноски журналов ГК зашита константа в 1000 строк (ограничение на размер bundle'а с одним или несколькими журналами), думаю, это - достаточно хороший ориентир.

Are you sure?
Судя по коду не все так однозначно.

[Pokersky09]

При разноске необходимо учитывать пределы, которые ограничены SQL сервером:
Кол-во соединений не более 32тыс (далее вылетают аосы).

В классах разноски используются UserConnection, которые генерят дополнительные соединения к SQL, и не всегда они быстро закрываются (отдельная тема, планируется на обсуждение).


Также разноска использует большой ресурс цп SQL, что влияет на производительность приложения и всего остального, при "выкручивании" количества потоков. Мы указывали кол-во потоков в 100, 700, и в конце пробовали в 2000.

На своем опыте, разноска журнала который содержит более 5-10тыс строк происходит заметно дольше, чем разноска более маленьких, но много.

Есть параметр в стнд.функционале, максимальное число строк в журнале, который при разноске предварительно создает новые журналы и перемещает туда строки. Указывал по 500 строк в 1 журнал.

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

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

Решением же проблемы с блокировками номерных серий(НС) будет снятие непрерывности, а также активация "предварительного" выделения номеров, что позволит сократить кол-во обращений к НС.

На текущий момент, примерная скорость разноски 50 журналов, включающих примерно 1млн строк в сумме, занимает порядка 6-10 часов.

На текущий момент возникают блокировки на запросах SQL:

INSERT INTO NUMBERSEQUENCETTS (TRANSID,RECVERSION,PARTITION,RECID) VALUES (@P1,@P2,@P3,@P4)

Также Insert в CustTrans занимает продолжительное время, что приводит к блокировкам.

Решил поделиться своим опытом, обсуждение приветствуется