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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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