Доброго времени суток, All!

Буду признателен, если подскажете что-либо по следующему случаю.
Несколько кубов MOLAP, собраны в прокси-куб через linked measures. Размер - средний, 700 GB, структура большая, более 300 групп мер. Процессятся через формируемый XMLA скрипт (описание как формируется - ниже). Стали происходить "зависания процессинга" - во время них активность SSAS практически нулевая. Но стоит обратиться к кубу с MDX запросом - процессинг возобновляется и вскоре завершается.
Воспроизводится на SSAS Server 2008, 2008 R2 и 2014.
Вопрос - что это такое и как лечить? ИМХО, поведение ненормальное.

Для справки - как формируется XMLA скрипт на процессинг. Группы мер в кубах партицированы. При обновлении данных в источниках - формируется перечень обновлений источников. По этому перечню подбирается список групп мер (через внутренние метаданные системы) и передается C# коду. В коде через AMO
- включаем CaptureXML
- ищем все измерения, делаем для них Process(Process_Update)
- ищем группу мер, и для нее запускаем метод Process(Process_Full)
- после исчерпания групп мер - делаем ConcatenateCaptureLog в строчную переменную
Далее полученный XMLA - выполняем в SSIS пакете.

мигель1Это понятно, зачем linked measures?
Если меры "живут" друг с другом почему не сделать меры "мени то мени" и управлять видимостью через перспективы?
Гм, куб большой с точки зрения метаданных , групп мер в нем более 300. Группы мер добавлялись тематически, поэтому разделены на свои кубы.
Была попытка слить кубы в один. Наблюдение - если в кубе с материальными партицированными мерами их сильно много - процессинг сильно тормозит на начальной фазе - составления плана вычисления. Разбиение куба на части помогает сократить время процессинга.

А "мани-мани" там тоже есть :)...

StarikNavy"во время них активность SSAS практически нулевая"
что то такое недавно на форуме проскакивало, может поиском найдете

Находил и сталкивались вот с этим ограничение SSAS по памяти . Но в этом случае симптомы несколько иные - весь сервер "висит", трудно даже зайти удаленной консолью, помогает только рестарт. А здесь - сервер не загружен, MDX запрос инициирует процессинг.

Словил симптомы снова, на SSAS 2014 SP1.

Выглядит так - идет Process Index изменившихся партиций после Process Data, много партиций в одной большой транзакции в параллель. Сервер с 4 CPU, бодро пережевывает 5-20 партиций одновременно (показатель Proc Indexes\Current partitions) и 200 000 - 700 000 строк в секунду, есть работающие processing I\O threads и non I\O threads, I\O threads завершаются 20-40 раз в секунду, секундный processing pool job rate колеблется от 0,3 до 2. Короче, жужжит.
Начиная с некоторого момента количество Proc Indexes\Current partitions растет до 96, количество завершенных I\O threads и processing pool job rate падает до нуля. В таком состоянии и висит, может провисеть и сутки. Помогает выдача MDX SELECT запроса к кубу, одновременно с этим процессинг магически возобновляется и завершается за 5-15 минут.
В общем, чудеса. Что покрутить еще - не знаю, буду признателен за идеи.

WarAntА сам xmla запрос не пробовали изучать?

Ошибок или косяков там нет. Много задач ProcessIndex на партициях в одной Parallel, уровень паралеллизма не установлен, регистрация ошибок в файл. Файл с ошибками пустой.

Игорь Бобаквот с "много задач в одной parallel" будьте осторожны.

я когда-то разработал свой процессор кубов, в нем предусмотрел ограничения, чтобы в одном parallel не шло больше Process команд, чем ядер на машинке.

до этого тоже все висло, когда сделал вот так с ограничением - начало железобетонно работать.

Спасибо, хорошая идея, попробую поиграться со степенью параллелизма. Вопрос к опыту - что ставить относительно кол-ва ядер, 1 ядро - 1 поток или можно 2? Похоже что SSAS слишком оптимистично тут работает, и заводит себя в тупик.

Новости с полей...

В XMLA процессинга прикрутил количество параллельных процессов = кол-ву ядер.
Запустил, на Process Index через некое время зависло с Proc Indexes \ Current Partitions = 8.
Одновременно вел профилирование. Начиная с запуска процессинга - кроме событий процессинга нет ничего.

MDX Select запрос к обрабатываемому кубу восстановил ход Processing.
Чудеса.

VicSOТакая проблема была виртуальной машине, проблема решилась заменой виртуальной ситивушки.
проблема была в то что при нагрузке, соединение не обрывалась, но и потока не было :(

Машина виртуальная. А что значит "замена виртуальной сетевухи" - пересоздание ее, что-ли, или иные настройки?

a_voroninFerdipux,

У вас там случайно не стоит Lazy Aggregations ?
Нет, Lazy Aggregations запрещен.

Игорь Бобаку меня стоит "к-во ядер умноженное на два", но я бы на вашем месте игрался начиная с к-ва ядер, и по чуть чуть увеличивал
Попробовал, выведя множитель ядер как параметр. К сожалению, зависание повторилось, даже с множителем 1. Так что попробуем открыть кейс в поддержке Microsoft.
Из интересного в этом - при множителе 1 и 2 - наблюдается явный недогруз CPU, так как очередь задач на процессинг не пуста и при этом загрузка CPU плавает в районе 40-60%.

КритикFerdipux,

На тестовой системе воспроизводится?
Если куб полностью переразвернуть из проекта (с удалением предыдущего) - ошибка воспроизводится?
Если развернуть проект на тестовом сервере DWH (где мало данных) - не воспроизводится.
Если развернуть проект на копии продуктива - воспроизводится.

КритикЕсли разбить скрипт на отдельные блоки: процессинг измерений, Process Data и Process Index?
Где повиснет?
Писал выше - Process Index. Process Update и Process Data идет без подобных зависаний.

КритикА если запустить прцоессинг сразу после рестарта службы SSAS - тоже виснет?
Какой - сразу Process Index, или сделать стандартный цикл - Process Dim Update, Process Cube Data, Process Cube Index?

Критиктак: Process Dim Update, Process Cube Data, рестарт, Process Cube Index
Ага, попробовал. Результат интересный.
1. Сделал как описано - Process Dim Update, Process Cube Data, рестарт, Process Cube Index. Процессинг Process Cube Index прошел без ошибок и довольно быстро.
2. Попробовал воспроизвести кейс с зависанием в процессе последовательного процессинга без рестарта. Кейс воспроизвелся. Что любопытно - "висящий" SSAS не останавливался из Service Manager - писал для сервиса статус Stopping.

Попробовать на физ машине не могу ввиду отсутствия доступных оных (там нужна не только машина, но и подключение к фабрике FibreChannel, а с этим все плохо) :(...

спокойный бобр,

У топикстартера (вашего покорного слуги) - после миграции на SSAS 2016 и поддержании последней версии CU - проблема не воспроизводится. База выросла до полутора терабайт.

Вот не соглашусь. Рекомендация про 15 М строк и 50 МБ размер - кочует из документа по производительности SSAS 2008. С тех по кое-что изменилось в лучшую сторону, у нас живут партиции и по 100-200 М записей.
А вот проблемы или недостатки дизайна движков FE/SE -- остались. Поэтому -- из своего опыта - когда в кубе очень (более 10 К) партиций - медленным становится построение планов выполнения запросов и обновления метаданных. К примеру, применение обновления метаданных 50 партиций из 15 К в кубе идет более часа.

a_voronin,

Slice/rigid rels on Data Dim - есть.
Many-2-many - тоже есть и довольно сложные, каскадные.
Версия SSAS - 2016, сейчас в тесте 2019 - особых улучшений в области производительности метаданных нет :(...
Обычные запросы откликаются нормально, а вот запросы изменения или процессинга - долго думают на этапе создания плана выполнения.

Я несколько некорректно описал проблему долгого изменения метаданных. Медленная обработка происходит при деплое изменений структуры куба (изменение свойств измерений или мер), не при обычном процессинге. Сразу уточню - изменение структуры идет без одновременного процессинга. Деплой идет через deployment wizard и указанный параметр не применим и отсутствует.
При росте числа партиций - обычный процессинг тоже тормозится, долгим становится построение плана обработки команды (фаза в начале процессинга). Из анализа загрузки CPU видно, что это строго однопоточный процесс, потребляет строго 1 ядро CPU, может занимать до 5 минут.

StarikNavy,

Это не план в понимании MS SQL, а план в понимании SSAS. То есть составление перечня объектов SSAS r процессингу и т.п.