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
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.