iCan Blog Archive

“i Can…Work With Your JVMs” was one of the very first ‘i Can’ blogs written. That blog covered the commands that were new in the IBM i 6.1 release for working with your JVMs.

Since that blog was written, additional interfaces have been added to the operating system that expand the ways in which you can work with your JVM jobs.

IBM i Services – Java Services
As I have blogged several times recently, IBM has been adding many IBM i Services that allow you to access system information via SQL. The Java Services allow you to review JVM settings; you can also specify settings for a specific JVM. These services are supported on the 7.1 and 7.2 releases and require relatively recent levels of the DB2 group PTF.

The JVM_INFO service allows you to retrieve information about an active JVM. You may specify the specific job you want to retrieve information about, or you can select from all active JVMs. This provides you a flexible, programmatic interface to analyze your JVMs. For example, using JVM_INFO, you can easily find the jobs that have been spending most of their time in garbage collection or using the most heap.

The SET_JVM procedure allows you to set information for a specific JVM. For example, you can set the enable or disable verbose JVM garbage collection as well as specify whether heap, system or JVM dumps are to be collected. The ability to generate heap, system or JVM dumps is similar to what you can do with the GENJVMDMP command. Note that previously, to specify whether to enable to disable JVM garbage collection, you had to use the interactive WRKJVMJOB interface. This SET_JVM services now gives you a programmatic interface to do this.

Collection Services – JVM Information 
In the 6.1 release, Collection Services began collecting information about each JVM. This data is stored in the QAPMJVM file and is similar to, but not quite the same as, the information the JVM_INFO service returns. A key difference between the two is Collection Services data is sampled at the collection interval, while the JVM-INFO information is from the point-in-time when the service is invoked. While you can retrieve information via the JVM_INFO service or the data in the QAPMJVM file, the richest interface for viewing information about a JVM is with WRKJVMJOB.

Collection Services also collects some basic JVM information for every job on the system. The QAPMJOBMI file has fields that indicate whether a JVM has ever been started in the job, as well as whether that JVM was active when the sample was taken. The data in this file also includes a field for the secondary threads within that job, indicating the type of work being done in that thread for the JVM.

IBM i Performance Data Investigator – Java Perspectives
You can review your JVM memory usage with the IBM i Performance Data investigator (PDI). The charts that are displayed with PDI are based upon the data in QAPMJVM file from Collection Services.

The nice thing with Collection Services data and PDI, is that you can review what has been happening with your system and the jobs over time, whereas the other methods are a snapshot of the current environment. The PDI charts allow you to look backward in time to see what happened the timeframe of interest. 

You find the Java perspectives under Collection Services –> Java. The screen capture below shows the two perspectives you can select.

The first one, IBM Technology for Java Memory Overview, provides a systemwide overview of Java memory use; the second one allows you to see this information by contributing job. In each of these graphs, you can display the heap and malloc memory used.

The screen capture below is an example of the Java Memory Overview chart, which displays the systemwide view of Java memory use.

This next screen capture shows the Java memory use by job. On my test system, it’s not too surprising that the largest user of JVM heap is the Admin2 server, which runs the Navigator Web console.

We all run Java, whether we realize it or not. These various interfaces provide additional ways to gain insight into what may be happening within your JVMs.

This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.