01.05.2014, 01:58 | #21 |
Banned
|
Еще кредитный лимит с учетом открытых строк имеет убийственный эффект на "длинных" заказах.
|
|
01.05.2014, 05:08 | #22 |
Участник
|
из собственного опыта - на числах близких к 1000 строк начинает нелинейно тормозить расчет налогов, но это поддается оптимизации
на числах за 3000 строк уже почему то уходит в небеса расчет корреспонденции CIL на время разноски влияет слабо, что странно конечно. скорость разноски пару строк в секунду ну то есть если не использовать налоги и корреспонденцию то наверное и 10 000 можно обрабатывать |
|
|
За это сообщение автора поблагодарили: R.Safianov (2). |
01.05.2014, 06:35 | #23 |
NavAx
|
Если правильно помню, важно не количество строк в заказе, а количество строк в разносимом документе. Т.е. если заказ на 10 тыс. строк будет разноситься как 100 накладных по 100 строк, то проблем возникать не должно.
__________________
Isn't it nice when things just work? |
|
01.05.2014, 12:34 | #24 |
Британский учённый
|
Именно, в моем предыдущем сообщении, как раз одна строка разносится как 10 тыс. Если не использовать номенклатуру с серийными номерами, тогда как одна строка разносится мгновенно. А к примеру продажа одной строки 10 тыс. симкарт превращается в разноску 10 тыс. строк, потому что они должны иметь уникальный серийник.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
01.05.2014, 16:08 | #25 |
Модератор
|
Цитата:
Таких заказов много в системе создается \ разносится одновременно ? С точки зрения масштабирования "решения" я бы предложил все же бить заказ на мелкие и разносить пакетной обработкой, иначе у Вас тут и там алгоритмических "мин замедленного действия" (см. выше) разложено чуток а исполнение - на одном процессорном ядре AOS-а, скорее всего виртуальном. Мы в принципе гоняем 800-900 строчные документы через AIF (вроде тьфу-тьфу справляется), но с другой стороны по-другому и не можем - это каталог, его по частям другая сторона не примет, не подавится ли на 10000 - интересно конечно но я бы постарался таких трюков избегать по возможности
__________________
-ТСЯ или -ТЬСЯ ? |
|
13.05.2015, 11:41 | #26 |
Участник
|
Подыму-ка тему
Кто-то пробовал разносить тысячи строк в накладных продаж / закупок в 2012?
__________________
Ivanhoe as is.. |
|
13.05.2015, 11:55 | #27 |
Модератор
|
Накладную по заказу на закупку размером более 2000 строк (в "российской" компании стандартным функционалом) разнести практически нереально. ИЧСХ - основные косяки на уровне локализации
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: Logger (3). |
14.05.2015, 11:05 | #28 |
Участник
|
Цитата:
Заказы разносился в рамках Retail (разноска стейтментов). До 1300 полет +- нормальный (бенчмарк тест от МС как раз дальше этой границы не пытается уйти). Дальше все печально... После исправления недочетов по расчету налогов разноска заказа на 2000-3000 строк занимает 40-50 минут. Время +- линейно увеличено по объему. Т.е. если разносить заказ кусочками по 100 строк, то суммарное время будет потрачено такое же. |
|
|
За это сообщение автора поблагодарили: ds1678 (2). |
14.05.2015, 12:28 | #29 |
Участник
|
Цитата:
Сообщение от IKA
Тут наш волшебный архитектор хочет загонять в систему через EDI заказы от клиентов по 10 000 строк в каждом. (т.е. это не разовый импорт заказов)
Я немного ошеломлена столь смелым, мягко выражаясь, подходом, но мне не хватает доказательной базы. Есть ли какие-нибудь документы (на english). которые анализируют перформанс подобных решений и требования к серверу? PS: У меня нету доступа к partnerSource, но если там есть что-то дельное по теме приведите плз линк. AX2012 R2 В 2012 R2 разноска накладных страдает старыми болячками: 1) При объемах больше 1000 тормозить начинает расчет налогов (вроде как правило расчета итогов меняли). 2) После "доработки" первого пункта на 3000 начинает тормозить корреспонденция. При этом на тестовой машине (4-е ядра, 30 ГБ оперативной) утилизация процессора падает до 40%, оперативная память съедается вся. Идет своп данных на диски и нагружает их очень сильно. АОС падает где-то через 4 часа без завершения задачи. 3) Параллельная разноска больших заказов приводит к взаимным блокировкам InventDim. После исправления первого пункта пробовал разносить заказы с 3000 строк в 4 потока. Поэтому пришлось еще с этим немного повозится. По результату оптимальное соотношение было достигнуто на уровне 8-ми потоков на один пакетный АОС. При этом разноска складских журналов идет на больших объемах (пробовал разносить 18000 - 26000 строк в одном журнале). |
|
|
За это сообщение автора поблагодарили: Logger (8), Ivanhoe (5), gl00mie (5), Kabardian (3). |
14.05.2015, 13:39 | #30 |
Участник
|
Цитата:
Вот этого Оптимизация класса Tax достаточно ? (для 2012-й - соотв. код сидит в PurchInvoiceJournalPost.writeTaxAmount_W() / SalesInvoiceJournalPost.writeTaxAmount_W() ) Именно InventDim ? Вы не опечатались ? Странно, откуда на InventDim блокировки. новые аналитики не должны бы создаваться. |
|
14.05.2015, 14:03 | #31 |
Участник
|
Цитата:
Сообщение от Logger
А как вы лечили 1-й пункт ?
Вот этого Оптимизация класса Tax достаточно ? (для 2012-й - соотв. код сидит в PurchInvoiceJournalPost.writeTaxAmount_W() / SalesInvoiceJournalPost.writeTaxAmount_W() ) Именно InventDim ? Вы не опечатались ? Странно, откуда на InventDim блокировки. новые аналитики не должны бы создаваться. По второму пункту точно на InventDim. В многопоточном режиме периодически простреливает сообщение: "Невозможно создать запись в Складские аналитики (InventDim). Номер аналитики.... Запись уже существует". Тут наверное даже не блокировки, а особенность выделения номеров в потоках. В какой-то момент InventDim созданный одним потоком не виден в другом потоке и создается повторно. |
|
|
За это сообщение автора поблагодарили: Logger (1). |
14.05.2015, 14:13 | #32 |
Участник
|
Спасибо за статистику. А такой крамольный вопрос - после разноски накладной, ТОРГ-12 и СФ реально сформировать?
По журналам ГК / складу подтверждаю. В CIL в целом разносится хорошо, и по 50 000 - 100 000 строк журналы разносил, в разы быстрее чем в той же 2009.
__________________
Ivanhoe as is.. |
|
14.05.2015, 14:25 | #33 |
Участник
|
Цитата:
СФ - формировались и включались в книгу продаж. Печать документов не смотрел. Для тех задач не было нужды. |
|
14.05.2015, 14:31 | #34 |
Участник
|
Меня именно печать волнует.
И кстати, про розницу. Никто не копал разноску? Субъективно заказ из стейтмента разносится намного быстрее, чем аналогичная накладная по обычному заказу. Нет ли там какой-то оптимизации именно для розницы?
__________________
Ivanhoe as is.. |
|
14.05.2015, 15:55 | #35 |
Участник
|
Цитата:
Оптимизация есть в агрегации строк. Но это к созданию заказа. |
|
14.05.2015, 20:35 | #36 |
Axapta
|
Иван, скажи, пожалуйста, каков был порядок времени разноски журнала ГК из 100к строк и на каком железе?
__________________
С уважением, Олег. |
|
18.05.2015, 12:40 | #37 |
Участник
|
Пока только по памяти:
100К журнал ГК - примерно 1,5 часа. Но тут сильно зависит от сложности фин. аналитик. 40К журнал склада - примерно 40 минут. В последние сколько-то лет стоимость железа стала намного ниже лицензий и услуг. Скажем так, от 16 ядер и 48Г на SQL, от 4 ядер и 8Г на один сервис АОСа. Указанные цифры примерно на таком же железе.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: oip (5). |