Comment 8 for bug 484779

Tuning Mondrian - well, I wish I could give you a simple, straightforward answer and list of values, but it is not that easy. Mondrian is a stateless multi-threaded server, and if the application throws a bunch of complex MDX queries on it simultaneously, or if it expects a lot of caching to take place, Mondrian will keep grabbing memory.

I have now reviewed my notes from the time when we tuned the WHOSIS project for production, and here is the best I could come up with. Also, it could make sense to force a Java garbage collection periodically, via the system.gc() call. The trick is that each time we "de-tune" something on the caching level, we get lower memory usage, but worse query performance.

Here are some suggestions:

# WHOSIS settings - assuming that GHO doesn't use pre-aggregated tables
mondrian.rolap.aggregates.Use=false
mondrian.rolap.aggregates.Read=false
mondrian.native.topcount.enable=true
mondrian.native.filter.enable=true
#mondrian.expCache.enable=true #see below, may be reset later
# Reduce "resource hogs" and too much concurrency, to allow base tests to complete
# If this doesn't work, try even lower values
mondrian.query.limit=4
mondrian.result.limit=50000
mondrian.rolap.evaluate.MaxEvalDepth=10
mondrian.rolap.queryTimeout=10
mondrian.rolap.IterationLimit=10
mondrian.rolap.star.disableCaching=true
mondrian.expCache.enable=false
# Try it initially with false, later change to true
mondrian.rolap.EnableRolapCubeMemberCache=false
# Hopefully get better memory diagnostics in the log
mondrian.util.memoryMonitor.enable=true
mondrian.util.memoryMonitor.percentage.threshold=75

The only other technique I can think about is by tuning the MDX queries, reducing cross-joins, remove unnecessary sort operators, possibly even reducing unnecessary hierarchy levels in the model. On that side, I do not really consider myself to be an MDX expert (I know only enough to be dangerous).