Доброго времени суток, 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%.