Hitachi Vantara Pentaho Community Wiki
Child pages
  • Monitoring Mondrian System Metrics with Java Management Extensions (JMX)
Skip to end of metadata
Go to start of metadata

Starting with Mondrian 3.7, you can monitor system metrics by using JMX.  This allows accessing real time information about the queries currently being executed on the server.  Aggregate metrics like cellCacheHitCount and sqlStatementExecuteNanos are also exposed for the server.  See the table below for the complete list of metrics with their descriptions.

JMX Configuration

In order to access Mondrian metrics from a JMX client, you'll need to first configure the JVM process running biserver.  For example, to set up unsecured remote JMX access on port 7199, add the following JVM parameters to the CATALINA_OPTS variable in

After restarting biserver, you should be able to connect using a JMX client (e.g. JConsole, Nagios, Splunk) with the connection string service:jmx:rmi:///jndi/rmi://servername:7199/jmxrmi.

See for more information on JMX configuration.

The screenshot below shows the MXBeans that are available.  Note that there are two separate namespaces for Mondrian metrics:  mondrian.server and mondrian4.server.  Separate namespaces allows metrics to be collected when both Mondrian 3.7 and 4.0 are running within the same container. If more than one instance of the same version of Mondrian is running within a container, each will be given a unique id (e.g. Server-1, Server-2, etc.).  


The following table lists the metrics available, along with a brief description.  Within the "Server" attribute these metrics are aggregated across the whole server.  Similarly, each Connection, Statement and SqlStatement object within their respective arrays have metrics aggregated at the appropriate level.  For example, querying the sqlStatementExecuteCount value of a Statement object will retrieve the total time spent in SQL execution for that single MDX statement.  Note that each of these attributes reflect the current state of the system.  Statements and Connections will be removed from the monitor on completion, but their aggregate statistics will be persisted.




The count of cache hits.


The count of cache misses.


A count of requests for cells that are in the process of being loaded into
the cache but are not yet ready


The total number of requests made for cells from the cache.


The number of cells currently in cache.


The sum of the dimensionality of every cells currently in cache.
For example, each cell in the segment (State={CA, TX} * Year={2011})
has two coordinates.
From this, we can compute the average dimensionality of segments
in cache, weighted by the number of cells. It gives an idea of the
memory overhead for segment axes.


The number of connections currently open.  Should equal 
  (connectionStartCount - connectionEndCount)


The number of completed connections.


The number of started connections.


A count of MDX statements that have finished execution. 


A count of MDX statements that have started execution.


The number of segments currently in cache.


The number of segments currently in cache.  This should be equal to 


The number of segments placed into the cache by an external cache.  For example,
if a segment is resolved on a peer node in a cluster and propogated to  this node.


The number of segments created by rolling up already loaded segments.  
For example, if the [Unit Sales] value for each of the children [Product].[Drink] is 
present in 2 or more separate segments, Mondrian may be able to roll up the values
to avoid an unnecessary SQL query.


The number of segments created by issuing SQL.


The number of segments deleted from an external cache.


Total, over all SQL statements that are fetching cells into cache, of 
the number of requested cells that will be satisfied by those SQL
statements. Note that a given SQL statement may round out the predicates
and bring back a few more cells than it was asked for.


number of SQL statements currently executing.
 (sqlStatementStartCount - sqlStatementEndCount)


number of SQL statements finished execution.  Incremented when the 
sql statement is closed.


The total number of SQL statements that have execution.   Incremented after
the SQL query has executed.


The total nanoseconds elapsed during SQL execution.


Total number of rows fetched.


The total number of SQL statements started.  Incremented immediately before 


The number of statements currently executing.  In some cases (e.g. when using
a PreparedOlapStatement) it's possible to execute the same statement more 
than once.


The number of statements currently open.  
A statement may have been opened but not yet begun execution.  This value
should equal (statementStartCount - statementEndCount)


The total number of completed statements.


The total number of statements started.  This number is incremented when the
statement is opened, before execution begins.



  • No labels