This content has been marked as final. Show 6 replies
I think every calculation that you run will take that 200 megabytes. So one calc = 200 MB, two calcs run simultaneously = 400 MB, etc., etc., etc. Just something to be aware of in a budgeting (like Planning) environment.
Just be aware that you need that amount of real RAM, otherwise you'll end up paging memory to disk.
FWIW, I try to always use as much calc cache as possible -- servers are big, memory is cheap, and hopefully none of the boxes I am running on are maxed out. It can help, some, with the calc time so I use it till I can't.
TimG wrote:ok, this is something I was afraid of. I cannot assume that calcparallel will not be upped to get a (in my opinion) cheap boost in calc performance, temporarily or permanently - and therefore putting the server at risk. We have a bunch of memory, but we also have a lot of calcs running every hour, and I am sure that the memory usage will quickly spiral in a "perfect storm" event.
I think you're right Cameron, and it's one calc cache per thread too, so be careful with high cache settings and CALCPARALLEL. Rick Sawa's post here has an excellent in-depth discussion: http://oracleinfogram.blogspot.com/2009/02/hyperion-essbase-optimization-what-is.html
Of course it would be nice to be able to be a little more granular with the calc cache setting in a calc script outside of the high/default/low settings, i.e. setting a value independent of the config file.....pipe dream probably.
Also, very interesting comment Rick makes (admittedly, now almost four years old) in that article:
It is important to know that searching through the bitmap is not indexed and results in the strong suggestion NOT to allocate more than 50 MB of RAM to the CALC CACHE, because the effectiveness of the CALC CACHE search algorithm tails off beyond 50MB. When Essbase is unable to achieve multiple bitmaps with a single anchor using 50 MB or less, break the so-called “hourglass” motif and move non-aggregating sparse dimensions below the last and largest sparse (anchor) dimension. The objective is to reserve memory for Essbase to be able to place as many aggregating dimensions as possible into the bitmap.Whether Rick's statement re 50MB still holds or not, I think you should be testing the CALC CACHE values to see where you actually get benefits (and then set no larger) - and thinking about it, you may see 'step' changes as different bitmap / anchor configuration are applied.
Clearly the interaction between CALCPARALLEL, CALC CACHE and outline order is complex (more complex than can be captured in a simple rule-of-thumb!).