OWLIM offers a number of management and control functions using Java Management Extensions (JMX). OWLIM uses this interface to provide information about its internal state and behaviour, including trend information, as well as operations for intervening in certain database activities.
After initialisation, OWLIM will register a number of JMX MBeans for each repository each providing a different set of information and functions for specific features. The JMX endpoint is configured using special system properties when starting the Java virtual machine (JVM) in which OWLIM is running. For example, the following command line parameters will set the JMX server endpoint to listen on port 8089, not require authentication and will not use a secure socket layer:
If using OWLIM with Tomcat, then these parameters must be passed to Tomcat's JVM by setting either the JAVA_OPTS or CATALINA_OPTS environment variable, e.g.
For some Linux distributions, you can also edit the file /etc/default/tomcat6 and set JAVA_OPTS there.
Once OWLIM is loaded, use any compliant JMX client, e.g. jconsole that is part of the Java development kit, to access the JMX interface on the configured port.
Statistics are kept for the main index data structures and includes information such as: cache hits/misses, file reads/writes, etc. This information can be used to fine tune OWLIM-SE's memory configuration and can be useful for 'debugging' certain situations, such as understanding why load performance changes over time or with particular data sets.
For each index, there will be a CollectionStatistics MBean published that shows the cache and file I/O values updated in real-time:
The following information is displayed for each MBean/index:
The following operations are available:
Ideally, the system should be configured to keep the number of cache misses to a minimum. If the ratio of hits to misses is low then consider increasing the memory available to the index (if other factors permit this).
Page swaps will tend to occur much more often during large scale data loading. Page discards will occur more frequently during query evaluation.
Information is also available that provides details about executing queries (or more accurately query result iterators). These statistics are provided through a SailIterationMonitor MBean, with one for each repository instance. Each bean instance is named using the storage directory of the repository it relates to.
The SailIterationMonitor Mbean has a single attribute TrackRecords that is an array of objects with the following attributes:
The collection of these objects grows for each executing/executed query, however older objects in the CLOSED state expire and are removed from the collection as the query result iterators are garbage collected.
There is a single operation available with this MBean:
This operation allows an administrator to request that a query terminates early. The operation is called requestStop and requires the trackId of the query that is to be stopped. If this operation is invoked on a running query, the isRequestedToStop flag is set to true and the next call to hasNext() will return false.
It is possible to contrive situations where committing an update transaction can take an excessive amount of time, e.g. if committing a 'chain' of many thousands of statements using some transitive property - the inferencer will attempt to materialise all possible combinations leading to hundreds of millions of inferred statements. In such a situation, it is possible to force a commit operation to abort and rollback to the state the database had before the commit was attempted.
The following MBean is used:
This MBean has no attributes and only a single operation:
Skip to end of metadata Go to start of metadata