Цитата:
Сообщение от
BOAL
теперь бытовые ноуты имею процы тех самых серверов и в однопользовательском режиме работают быстрее (парадокс, который и вызвал непонимание), чем на боевом дорогущем сервере. Так как в один поток серверное одно ядро вполне сопоставимо (а то и ниже по частоте) проца бытового ПК.
Ахиллесова пята бытовых ноутов - медленный винт. Если у вас не ssd-винт под капотом, то на операциях, упирающихся в дисковую подсистему, ноут сольет сопоставимому по прочим параметрам серверу.
Цитата:
Сообщение от
BOAL
Если в БД что-то долгое считается 1 час, то когда данных будет х2, будет условно считать 2ч. И железкой это не лечится, тк ничего не даст.
Может дать за счет большего об'ема оперативки и более быстрой дисковой подсистемы.
Цитата:
Сообщение от
BOAL
Нужно предварительно переписать логику на многопоточность.
Да, и вот там масштабируемость себя проявит.
Вот тут приводились кое-какие результаты оптимизации работы скриптов конвертации базы: если календарного времени было затрачено меньше 7 часов, то СУБД с учетом распараллеливания работы потратила больше 76 часов процессорного времени.
Цитата:
Сообщение от
BOAL
Ну или в данной ситуации проблема так остро (в х2 раза) не встанет из-за более умного SQLа, который заюзает ядра все подряд, даже на 1 селект (надеюсь это так?).
Чудес не бывает. Либо надо хинтами подсказывать СУБД, какие запросы распараллеливать (а из штатного Х++ это не сделать - только прямыми запросами), либо параллелизм погубит производительность мириад быстрых простых запросов, характерных для OLTP-системы.
Цитата:
Сообщение от
BOAL
Есть же куча старого софта который не знает о многоядерности. И внутри ОС Виндовс этот софт занимает все ядра по 100%
ничего подобного - такой софт грузит в каждый момент времени максимум одно ядро, иначе быть не может при отсутствии многопоточности.
Цитата:
Сообщение от
BOAL
Значит как это это работает и без переписывания на потоки, может не столь эффективно, как заложенное в коде деление, но работает.
Представьте, что у вас есть проездной на метро на 60 поездок и 59 приятелей, которых надо провести с собой в метро, но проездной можно передать только после того, как турникет окажется пройден. Какая вам разница, сколько параллельно стоящих турникетов в вашем распоряжении? И то, что в данной ситуации проходить турникеты может одновременно больше одного человека, всего лишь иллюзия или самообман. То же и со старым софтом, который не заточен под многопоточную работу.