Исходные данные:
Windows: 2016 Standart
Процессор: 2 Xeon E5-2697 v4 (18 ядерные) - 72 потока
Диски: полка SSD (20Тб) - c пиковой скоростью 3Гб /сек
ОЗУ: 1.5Тб (Терабайт)
SSAS: 2019EE

Куб на полном объеме процессился на SQL-2008R 6.5 часов на 64 потоках
Сейчас процесс идет более 12 часов -- пока не окончился ....

Куб:
10 групп мер в среднем по 20 показателей
Примеры групп
Остатки: 12 млрд записей - 1.2ТБайт
Продажи: 4 млрд записей - 400 Гб
10 групп many-to-many -- применены для быстрого расчета DistinctCount

Общий размер хранилища 3ТБайт - данных для OLAP

В хранилище данные разделены на месячные секции : размер секций для остатков 50Гб в среднем, по продажам 15Гб

Группы мер разделены на партиции по дням максимум 12млн записей на пратицию, параметр Slice определен

Настройки SSAS:
HardMemoryLimit = 70
TotalMemoryLimit = 60
LowMemoryLimit = 50

Query\MinThreads = 36
Query\MaxThreads = 72

Process\MinThreads = 180
Process\MaxThreads = 360

CoordinatorExecutionMode = -36
FlightRecorder\Enabled = 0

CoordinatorQueryBalancingFactor=1
CoordinatorQueryBoostPriorityLevel=0

RandomFileAccessMode=0

FactPrefetchMode = 1

Где еще копать ?
MS SQL настроен оптимально

Перевел и XD и SSAS

Проект SSAS был подготовлен на 2008 для 2019 просто сконвертил и пытаюсь сделать процессинг на 2019 -- тормозит (14 часов уже процессит) .
Тот же проект на тех же данных и оборудовании на 2008R2 6.5 часов процессится
настройки OLAP те же самые кроме RandomFileAccessMode

Организация: торговая сеть 10 тыс магазинов, 2 тыс активных товаров (всего с архивными 17 тыс)
Поддержкой занимаюсь 1 , данные закачиваются из полностью самописной 1с8 ,
Загрузка / выгрузка с помощью BCP и BULK INSERT, подготовка XD за 1 день около 1 часа
Измерения маленькие

Премьер-поддержки от MS - нет

Вопрос то в том что SSAS 2008R2 обрабатывает все нормально - источник XD один и тот же
Статистику обновить на MS SQL -- возможно в этом проблема - но 2008-му это не мешает

Поставщик данных (Data Provider) имеет значительное влияние на то, как быстро Analysis Services может потреблять поступающие данные с источника. Смените провайдер с SQL Server Native Client на Microsoft OLE DB Provider for SQL Server, пропускная способность может повыситься на 30%. Правда, компания Microsoft заявляла, что OLE DB станет устаревшей функцией
-- Источник: https://www.dvbi.ru/articles/reading/SSAS-optimization


Пользовался для SQL-2008 такой рекомендацией - возможно ODBC на 18.3 надо обновить

Все совершенно верно

--- тормозит процессинг только на новом SSAS

Один и тот же сервер
Один и тот же источник данных
Одна и та же сеть
Диск один и тот же для сборок

Наибольший вклад в тормоза -- агрегация данных
Такое впечатление по 3 раза агрегации обходит
Cмотрю на диск каталог Data -- размер каталога не меняется -- хотя монитор системы показывает что интенсивно пишет .
В Temp вообще пусто - так как это сборка первый раз

Нет . Попробуем в эту сторону покопать

Все совершенно верно

--- тормозит процессинг только на новом SSAS

узкое место нашел
processing data,index - все нормально скорость очень высокая доходит запись/чтение до 2Гб сек когда доходит до агрегатов скорость падает до 33 Мб сек и молотит бесконечно, чтения SQL базы уже совсем нет

Как вариант дизайн агрегатов заново сделать на 2019

Ускорить этот этап агрегаций настройками никак нельзя ???

Спасибо не знал

Вот как раз и переразворачивал
Вот в том и дело что все помечено - под руководством службы поддержки

Это точно -- делал агрегаты до дня

Вчера переделал:
1. Агрегаты - убрал уровень день
2. Убрал many-to-many заменил на DistinctCount

Вроде залетало - но так и не получилось собрать - не хватило места для TempDB SQL (было на RAM) - включу оптимизацию TempDB для 2019

Дело в том , что MS SSAS 2008 нормально все скушал при переносе базы на SQL 2019
И основная проблема была не в получении данных - а в дизайне агрегаций и избыточных many-to-many

a_voronin,

Понятно что немного другая тема
Но когда создавались агрегаты увидел что куча полей измерений по которым при агрегации установлено None в каждую партицию копируется
Данные поля - не используются в итогах - это просто свойства измерений

Если сделать IsAggregation = False ничего страшного не произойдет ?

У меня как-то не было до этой работы больших кубов - 2Тб - в основном мелочь была до 100Гб и особых настроек не требовалось

Спасибо
Как бы так и делаю.

Пока готовый куб не превысил 2Тб и время не зашкалило за 6 часов
об оптимизации не задумывался.
3-4 часа на процессинг при объеме готового куба 1Тб вполне устраивало .

Структуру измерений не думая перенес из 1С вместе с типами и размерами, придется уплотнять неявными преобразованиями через View

Взрывного роста объема не предвидится (все большие факты уже готовы)
У аналитиков плавающее окно данных - 3 года им достаточно .
Максимум предполагаю в 2 раза вырастет
Обновления за 1 день укладываются в 1 час -- круглосуточной работы аналитиков не предвидится .