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

[fed]

Цитата:

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

Раньше это прокатывало, тк сервера становились мощнее (частоты и кэш одного ядра). Теперь прогресс встал колом - увеличивают ядра.
Если в БД что-то долгое считается 1 час, то когда данных будет х2, будет условно считать 2ч. И железкой это не лечится, тк ничего не даст.
Нужно предварительно переписать логику на многопоточность.
Ну или в данной ситуации проблема так остро (в х2 раза) не встанет из-за более умного SQLа, который заюзает ядра все подряд, даже на 1 селект (надеюсь это так?).

SQL, в общем случае, умеет распараллеливать исполнение операторов на несколько потоков. Только для этого нужно, вопреки микрософтовским рекомендациям по использованию SQL с Аксаптой, разрешить это распараллеливание установив у SQL-сервера параметр MAXDOP (максимальное число процессоров на запрос). Вообще это долгая тема - покопайся в интернете как это настраивают. Но в любом случае - выгоднее из аксапты выполнить малое количество сложных, потенциально распараллеливаемых операторов (типа insert from select) чем очень большое количество примитивных селектов.

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

Ахиллесова пята бытовых ноутов - медленный винт. Если у вас не ssd-винт под капотом, то на операциях, упирающихся в дисковую подсистему, ноут сольет сопоставимому по прочим параметрам серверу.

Цитата:

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

Если в БД что-то долгое считается 1 час, то когда данных будет х2, будет условно считать 2ч. И железкой это не лечится, тк ничего не даст.

Может дать за счет большего об'ема оперативки и более быстрой дисковой подсистемы.

Цитата:

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

Нужно предварительно переписать логику на многопоточность.

Да, и вот там масштабируемость себя проявит. Вот тут приводились кое-какие результаты оптимизации работы скриптов конвертации базы: если календарного времени было затрачено меньше 7 часов, то СУБД с учетом распараллеливания работы потратила больше 76 часов процессорного времени.

Цитата:

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

Ну или в данной ситуации проблема так остро (в х2 раза) не встанет из-за более умного SQLа, который заюзает ядра все подряд, даже на 1 селект (надеюсь это так?).

Чудес не бывает. Либо надо хинтами подсказывать СУБД, какие запросы распараллеливать (а из штатного Х++ это не сделать - только прямыми запросами), либо параллелизм погубит производительность мириад быстрых простых запросов, характерных для OLTP-системы.

Цитата:

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

Есть же куча старого софта который не знает о многоядерности. И внутри ОС Виндовс этот софт занимает все ядра по 100%

ничего подобного - такой софт грузит в каждый момент времени максимум одно ядро, иначе быть не может при отсутствии многопоточности.

Цитата:

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

Значит как это это работает и без переписывания на потоки, может не столь эффективно, как заложенное в коде деление, но работает.

Представьте, что у вас есть проездной на метро на 60 поездок и 59 приятелей, которых надо провести с собой в метро, но проездной можно передать только после того, как турникет окажется пройден. Какая вам разница, сколько параллельно стоящих турникетов в вашем распоряжении? И то, что в данной ситуации проходить турникеты может одновременно больше одного человека, всего лишь иллюзия или самообман. То же и со старым софтом, который не заточен под многопоточную работу.