How to use JVisualVM to Monitor your integration runtime

Document created by frank_wetzler970218 Employee on Mar 25, 2017Last modified by Adam Arrowsmith on Apr 3, 2017
Version 13Show Document
  • View in full screen mode

This document provides an overview for using JVisualVM which is a free JMX compliant application capable of monitoring your integration runtime (e.g. Atom, Molecule, or Atom Cloud) to ensure availability and performance for your production environment. This is especially important for local runtimes that are installed and managed by your team.

 

 

Reference Guide Articles

Here are some links to our Reference Guide, which you may find useful for an overview of Monitoring your Runtime environments.

 

Scenarios on How to Use JVisualVM to Monitor your environment

 

Scenario 1 - How do I configure JVisualVM ?

 

The first step is to configure your atom, molecule or cloud to enable monitoring. See Enabling remote JMX on an Atom for the simple steps require to enable monitoring for your integration environment. 

 

Once JMX monitoring is enabled, the next step is to install and configure JVisualVM. See Configuring Java VisualVM for JMX management to complete the installation and configuration. Note you can install JVisualVM on the same host where atom(s) execute or a remote host. 

 

Once JVisual VM is installed and configured you can monitor the atom.exe/atom.sh OS process. For Molecules and Private Clouds, monitor the atom.exe/atom.sh OS process on each node in the cluster. Each atom.exe/atom.sh OS process running on each node can be monitored using a single JVisualVM instance as the <hostname> in the <hostname:port> used to establish the JMX connection will be distinct for each node in the cluster.

 

Scenario 2 - What can I monitor in my integration environment using JVisualVM ?

 

For local atoms and Molecules running in multi-threaded mode monitoring through JVisualVM will include the following:

  • An overview of the atom configuration
  • An overview of the system resource consumption each atom is consuming
  • Metrics on process executions running within the atom.

 

For Clouds and Molecules meta-data about process executions across the Molecule or Cloud cluster will be available through various JMX parameters however metrics on system resource consumption such as cpu, heap/meta space, and thread activity regarding specific process execution will not be available through these techniques. 

 

The examples used below are based upon a connection to a local atom where the <hostname> is 'localhost' and the JMX connection is established over <port> 5002. 

 

One the JMX connection is established you will see a series of Tabs underneath the JMX connection just established. The tabs are {'Overview', 'Monitor', 'Threads', 'Sampler', and 'MBeans'}

 

Available types of information available regarding the atom

 

The 'Overview' tab provides the set of JVM arguments and System properties used to configure the atom. These include those found in the atom.vmoptions file. 

 

JVM arguments and system properties

 

The 'Monitor' tab provides information on the main atom running on a node regarding several key aspects regarding system resource consumption. These include:

  • CPU usage and percentage of time spend in garbage collection
  • Heap and Meta space memory consumption
  • Number of Classes loaded into JVM
  • Thread activity

 

Note these metrics are not relevant for the various forked executions which may also be running on the node. 

 

Monitoring System Resources

 

The 'Thread' tab provides information on states of the various threads executing within the JVM.

 

 

The 'MBeans' tab provides data on the various JMX counters available regarding the atoms performance. See JMX attributes for a complete listing of the available attributes. However, note that some attributes are only available for Clouds and Molecules.

 

JMX Attributes

  

 

FAQ

Should I use JVisualVM to monitor forked executions ?

During normal monitoring operations of Clouds and Molecules forked executions do not require monitoring as they only exist for single process execution. Once they terminate all system resources associated with the forked execution are returned to the operating system. In general, troubleshooting a forked execution's consumption of system resources can be done using operating system tools. If necessary, other tools are available to generate heap and thread dumps for forked executions which can be made available to Dell Boomi support for analysis. See How to generate a jvm Heap dump for troubleshooting issues and How to generate a jvm Thread dump for troubleshooting for additional details regarding these tools and their usage.

9 people found this helpful

Attachments

    Outcomes