Существенное снижение производительности после перехода на AX 2009 с Axapta 3.0

[fed]

Цитата:

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

Там оч много запросов, отчет только на чтение.
Но, если поведение, что 1 чел всегда занимает 1 поток верна, то получается, что масштабирования увеличением железкой (сервера) не добиться. Так что ли?
А как за пакетные операции, оно тоже будут 1 процессор занимать?
Вместо работы операции ночной за 10 мин, будет 3часа... оч печально

Получается, что для АОС АХ нужно брать какой-нть высокочастотный проц АМД без НТ, которое в данном случае вообще зло (делит процессор пополам).

Все это пока домыслы по мотивам приведенного выше.

Посмотри на то как вот этот вот отчет написан: axinthefield: Reconciling Inventory to GL in Dynamics AX
Они там порождают кучу хелперов на батч-сервере как раз для того чтобы запросы с многих ядер кидать. Я сам как-то написал мегазадачу для распределения себестоимости продаж по ABC. У меня основная задача порождала кучу хелперов, с зависимостями между ними. Батч сервер их там сам распараллеливал между ядрами (параллельных хелперов было больше чем ядер) и сам запускал новые задачи после того как те задачи, от которых они зависели, завершались. В итоге - миллион с копейками записей с распределениями (не в ГК, просто в отдельную таблицу для анализа), на батч-сервере с 4 ядрами создаются за полчаса в среднем (Это еще включая рассчет промежуточных таблиц с базами для распределения).
Так что механизм крайне полезный и могучий, надо просто большие отчеты и задачи заранее проектировать с идеей что они будут на батч-сервере во многих параллельных задачах исполняться.

P.S. Что-то мне кажется что идея эммулировать один мощный проц из множества ядер путем виртуализации не сработает. Если бы это было возможно, Intel бы давно делал одноядерные (с виду) процессора, внутри состоящие из кучи RISC-ядер. Они ведь и пошли по пути увеличения числа ядер, только потому что увеличивать производительность одного ядра не смогли...