Note
This documentation is for the new OMERO 5.1. version. See the latest OMERO 5.0.x version or the previous versions page to find documentation for the OMERO version you are using if you have not upgraded yet.
Once you have your OMERO server running and secured, a second critical step will be tuning various configuration parameters in order to get optimal performance.
OMERO should automatically configure itself to take advantage of the physical memory installed on a system whilst leaving room for other services. You may wish to override the defaults on a production server, for instance if your machine is solely dedicated to running OMERO you can increase the amount of memory that OMERO will use. You may also need to modify your settings if you are seeing out-of-memory errors when dealing with certain types of images.
A number of configuration properties starting with omero.jvmcfg control the calculation of how much memory to allocate to various OMERO services on startup, most importantly:
Configuration properties can either be applied to all three service types at the same time by omitting the service type (e.g. omero.jvmcfg.strategy) or to each individually by including it (e.g. omero.jvmcfg.strategy.blitz).
For example, the default, PercentStrategy, is equivalent to making the call:
$ bin/omero config set omero.jvmcfg.strategy percent
This could be changed to use the ManualStrategy for all servers:
$ bin/omero config set omero.jvmcfg.strategy manual
A couple of strategies are available for calculating the effective JVM settings from the provided configuration properties.
$ bin/omero config set omero.jvmcfg.percent.blitz 50
would raise the blitz heap size to 50% of the system memory seen.
$ bin/omero config set omero.jvmcfg.system_memory 24000
would set the system memory seen to 24GB regardless of the actual amount of memory present in the system. The PercentageStrategy would use this as the basis for setting the Java heap sizes for all services.
$ bin/omero config set omero.jvmcfg.max_system_memory 64000
would raise the maximum system memory seen by an OMERO installation to 64000MB of system memory. Assuming there was at least 64000MB of memory installed blitz would default to using 9600MB.
$ bin/omero config set omero.jvmcfg.strategy.indexer manual
$ bin/omero config set omero.jvmcfg.heap_size.indexer 2000
would set the indexer heap size to 2000MB without modifying the settings for the other services.
View the memory settings that will apply to a newly started server.
$ bin/omero admin jvmcfg
After modifying any memory settings, be sure to restart your server.
$ bin/omero admin restart
See also
In addition to watching the OMERO log files, the JVM itself provides a number of tools that you can use to determine the health of your server. JVisualVM, for example, can be used to visualize the memory use of each JVM:
You will need to have the PID for the service you want to monitor, which will usually be the main Blitz process. You can find the PID either via omero admin diagnostics or alternatively via the jps command found in the JDK.
Another tool, JConsole, also provides access to the memory statistics for your JVM, but also lists the JMX management beans which provide extensive information about the running process. Information includes the number of queries that have been run, the number of open file handles, the system properties that were set on startup, and much more. Further, the ome.system.metrics package makes use of JMX to expose further properties.
With further configuration, JMX properties can also be accessed remotely which can be very useful for monitoring your server with Check_MK, Nagios, Zenoss, or similar. However, care must be taken to protect the exposed ports.
Note
The commands above require the Java JDK as opposed to the JRE.
Building on top of the Codahale “Metrics” library, OMERO provides the ome.system.metrics package which measures a number of internal events and makes them available both via JMX as described under Monitoring but also prints them to the log files.
By default, these values are printed to each of the JVM-based log files (e.g. var/log/Blitz-0.log, var/log/Indexer-0.log, etc) once per hour. This value can be configured via omero.metrics.slf4j_minutes. A typical value might look like:
11:28:18,923 INFO [ ome.system.metrics] (r-thread-1) type=TIMER, name=ome.services.fulltext.FullTextIndexer.batch ...
Values include basic statistics (count, min, max, mean, etc.) as well as 75th, 90th, 95th, etc percentiles. Further, the rate over the last minute, the last 5 minutes, and the last 15 minutes is provided (m1, m5, m15). For example:
Useful metrics include: