Identifying permanent generation problems with jstat

The permanent generation is a special part of the HotSpot JVM's memory, which stores "class templates"' for the JVM class loader to use when creating and removing objects.

jstat is a JVM command-line tool, which shows you a number of statistics regarding how the JVM is performing.

In this recipe, we use jstat to understand the size of the permanent generation.

Getting ready

You will need SOA Suite installed for this recipe, and will need permission to execute the domain control scripts, as well as the HotSpot JVM tools. This recipe assumes that your SOA Suite application is running such that we may run jstat against it.

The tools jps and jstat are included with both the HotSpot and JRockit JVMs. For brevity, this recipe assumes that you have the relevant bin directory on your path. If you do not, simply use the fully qualified paths to the relevant bin directory.

This recipe assumes you are using HotSpot, as JRockit does not have a permanent generation.

How to do it…

1. Use JPS to determine the process ID of your SOA Suite server; see step 1 of the Identifying New Size problems with jstat recipe.

2. Use the jstat command to view the sizes of the survivor spaces and Eden:

   jstat -gc -h10 <pid> 2000

   The metrics we are interested in are PC and PU. PC is the capacity (size) of the permanent generation (in KB), and PU is the utilization of the permanent generation (in KB).

3. We want to see that PU is around 80 percent or less of PC.

How it works…

jstat is a JVM tool that can be used to view a number of runtime statistics regarding the JVM. The option –gc printsthe statistics about garbage collection, including the capacity and utilization of each memory pool. In the preceding example, the parameter –h10 prints the headers every 10 lines, to make the output easier to read, and 2000 is the time in milliseconds between each sample (2 seconds).

Permanent generation is the section of JVM memory that is used to store classes and other objects that cannot be represented as Java types. The larger a SOA Suite application is, the more classes it will contain, and the more permanent generation it will need. If the permanent generation is too small, classes will need to be unloaded and reloaded in the permanent generation, causing full garbage collections to occur, and a performance hit. We want permanent generation to be large enough to hold all the classes in your SOA Suite application, with a little overhead for other resources, so if the utilization of the permanent generation is around 80 percent of its capacity, we should have sufficient overhead to prevent classes needing to be unloaded.

See also

• The Setting the permanent generation size recipe