Hyperion Essbase Optimization: Настройки кеша калькулятора

What is the Calc Cache?

Calc Cache – занимает ключевое место в связке между ядром Essbase и другими промежуточными облостями памяти Essbase BSO. Он используется калькулятором не для хранения данных, но содействует агрегации, когда требуется рассчитать и создать блок верхнего уровня.

Essbase использует CALC CACHE для отслеживания иерархии и связей между узловыми элементами и их потомками. Его сущностью является то что он хранит в себе связи между элементами, что бы при создании блоков, во время агрегирования , избежать операций внешних вызова – например чтение описаний метаданных ( в outline).

Эффективные настройки CALC CACHE строго зависят от многомерной модели и его метаданных. И процесс настройки, построен на сравнении и тестировании всего, начиная с настроек памяти, расположении направлений в outline, изменении настроек плотного/разряженного направлений, и даже логики расчета.

Essbase разделяет разряженные (sparse) направления на две группы : те которые стремятся быть якорями ( являются глобальными метками – версии,сценарии,года) и прочие – стремящиеся быть bitmap измерениями и, соответственно, распределение памяти напрямую зависит от размера и кол-ва этих (второго рода) направлений.
Существует несколько путей настраивания использования CALC CACHE – среди из них одним из эффективным является распределение в outline направлений основываясь на кол-ве элементов в разряженных направлениях по правилу от меньшего к большему. Данное решение основывается на том, что CALC CACHE эффективно распределяет память для единичных «якорных» направлений, оставляя достаточно ресурсов для хранения «bitmap» направлений, располагая самое большое направление внизу иерархий, исключает его из списка «bitmap» направлений, тем самым уменьшая требования к выделяемой памяти. Тем не мене парадигма «песочных часов» не является универсальным решением для всех возможных моделей. Однако, существуют приложения, для которых нужно использовать другой подход за счет изменений в порядке направлений.

Каждый куб должен настраиваться индивидуально, что бы выработать свои настройки памяти CALC CACHE ( и даже CALC CACHE OFF ) . Так же настройки CALC CACHE следует изменять совместно с CALC PARALLEL


Важно так же понимать что поиск через bitmap направление не индексируется и результат не сможет превысить более 50 Mb, так как срабатывает алгоритм в ограничении CalcCache. Если у Essbase не получается распределить для multiple bitmaps с единичным якорем используя меньше 50 MB, то нужно изменить настройку иерархий «песочные» часы и передвинуть не консолидируемые разряженные направления ниже самого большого напраления. Это позволит зарезервировать больше памяти для переноса направлений в Bitmap.


Любой, кто тестирует использование CALC CACHE и CALCPARALLEL вероятно отмечали возможную взаимосвязь между двумя этими командами. Это связано с тем что каждый поток (thread) а расчете консолидации порождает требующейся ему CALC CACHE. Это не просто для Essbase справляться со множеством потоков агрегации и распределения памяти. И кроме того выделение большей памяти для CALC CACHE с использованием CALC PARALLEL это один из способов гарантированной дестабилизации Essbase.

Например, 32 битное приложение Planning, запустило 5 конкурентных правил расчета. Каждое правило использует CACHE HIGH (CALC CACHE HIGH настроено в Essbase.cfg на значение ~200 million bytes) и CALCPARALLEL 4 это приведет к утилизации более чем (5 x 4 x 200 million) ~ 4GB of RAM

З.ы. похоже «драка» в памяти конкурентных CALC CAHE является основной причиной падения производительности( поcле IO) при параллельных расчетах.