Есть NLB кластер из 2 серверов:
сервер1 с 2 процами: https://ark.intel.com/ru/products/52576/Intel-Xeon-Processor-X5690-12M-Cache-3_46-GHz-6_40-GTs-Intel-QPI
сервер2 с 2 процами: https://ark.intel.com/ru/products/64583/Intel-Xeon-Processor-E5-2680-20M-Cache-2_70-GHz-8_00-GTs-Intel-QPI
Вычислительные мощности процов примерно равны, может быть сервер2 даже должен быть чуток мощнее.
Настройки SSAS одинаковые на обоих серверах, настройки винды тоже одинаковы.
Различается только железо (у процов, кстати, разные наборы команд) и версии биоса

MDX запросы к SSAS OLAP на сервер1 выполняются в 1.5 раза быстрее чем на сервер2. Как такое возможно?
Это не случайное совпадение, наблюдаем уже около месяца. Запросы распределяются NLB произвольно. Даже сами выполняли запросы - сервер тормозит. Заметил что когда нагрузка растёт (несколько минут проц на 100% загружен), то сервер1 начинает сильно потреблять оперативу, затем отпускает её по мере спадания нагрузки. Сервер2 оперативу в таком количестве не потреблял, даже почти не затронул её.

Есть идеи что может быть, куда смотреть?

ShIgorMax_11111,
идеи есть: 3,46/2,70 = 1,28 раза
На нём ядер больше, так что если перемножить частоту на ядра, то выйдет примерно одинаковая величина.
Т.к. SSAS очень хорошо параллелится по ядрам, я предположил что ему относительно пофигу на частоту одного ядра, если их будет куча.

vikkivMax_11111,
1) запросы состоят из множества этапов каждый из которых это операции разных классов (от чтения дисков, агрегаций, расчёта формул, кэжирования и пр.) некоторые из которых строго однопоточные - выясняй что именно тормозит и от туда уже копай.
2) подозреваю что код ядра SSAS MD особенно не менялся с 2008-го года - это по поводу новых инструкций, но я в этой части архитектуры железа и использования функциональности прог.обеспечением и их влиянием на производительность не дока.
3) Если тормозит именно расчёт формул на лету, то как уже указал ShIgor выше: у тебя явно проц на первом быстрее на 28% хотя и BUS медленнее с кэшем поменьше
4) Смотри скорость памяти (и её обьём) и дисков, что там ещё на сервере крутиться (есть-ли дополнительная нагрузка и резервация памяти), в конце концов настройки самого SSAS Instance (если обьёмы памяти разные)
5) Даже если железо одинаковое - версии CU на SQL Server могут отличаться.

в общем пока только гадание по поводу наиболее вероятных причин.
3) да, тормозит расчёт формул
4) настройки и версии SSAS одинаковые, конфиг оборудования гляну. Но я больше на проц грешу, т.к. по монитору ресурсов нагрузка на диски была минимальной, а память не особо юзалась.
5) Да, немного отличаются версии, но по описанию CU были изменения только в SSIS, при этом SSAS не трогался

ShIgorдобавлю насчет кэша..

что его больше, здесь особой роли не играет. т.к. это кэш 3 уровня и является общим для всех ядер.

а вот кэш 2 уровня, которого в общем объеме одинаково, но под каждое ядро свой участок, влияет значительно сильнее, т.к. на первом проце на каждое ядро его тупо на 30% больше да и частота, как я уже и говорил выше.

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

Кажется я нашёл причину, только причина этой причины пока мне не понятна.
В общем взяли на пару дней более мощный сервер и я заметил что проц грузится только на 1/3, то есть примерно 24 ядра загружены OLAP, даже если запускаю несколько запросов.
На сервер2 тоже была нагрузка на сервер 75%-80%, что соответствует 24 ядрам SSAS.

Поискав в интернете я не нашёл каких-либо настроек SSAS, указывающих сколько ядер использовать при запросах (есть только ограничение при LazyProcessing, но это явно не то).
Вопрос: где это настраивается? либо же это регулируется лицензией на SQL Server?

Max_11111Вопрос: где это настраивается? либо же это регулируется лицензией на SQL Server?
В общем взял у админов более широкую лицензию и задействовал все ядра.
Потестировал на запросах - судя по всему производительность "более мощного сервера" примерно совпадает с производительностью "сервер1", при том что ценник на них разнится на порядки. Похоже что частота ядер больше влияет на скорость выполнения MDX запросов, чем их количество

КритикMax_11111,

это очевидно, т.к. формульный движок однопоточный
Мне это было не очевидно :)
Можно подробнее? что именно однопоточное а SSAS OLAP, а что многопоточное? Если есть, то дайте ссылки на соответствующие статьи

ShIgor,
Критик,

Спасибо, теперь всё стало намного понятней.
Особенно понятно почему остатки товаров так сильно тормозят - там почти весь расчёт на MDX написан.
Тогда такой вопрос: У меня считаются остатки на конкретный день как остаток на начало месяца + сумма движений с начала месяца до этого дня. Если я буду считать не по месяцам, а по неделям (т.е. объём данных для вычисления сократится примерно в 4 раза) - это ускорит расчёты? Я это ещё протестирую, но сейчас интересно чего можно ожидать.

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