Identifying new size problems with jstat

jstat is a Java Virtual Machine (JVM) command-line tool, which shows you a number of statistics regarding how the JVM is performing. In this recipe, we will use it to understand how large the new size is, and how frequently it is filling up.

Getting ready

You will need the SOA Suite installed for this recipe, and will need permission to execute the domain control scripts, as well as the JVM tools. This recipe assumes that your SOA Suite application is running under a normal load.

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.

How to do it…

1. Use JPS to determine the process ID of your SOA Suite server.

   jps –v

   The process ID is the number in the first column. The SOA Suite server can be identified by the command-line options that the JVM has. If you have multiple SOA Suite servers running on the same machine, you can identify the relevant server by the –Dweblogic.Name parameter, as shown in the following screenshot:

   

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 S0C, S1C, EC, and OC. These are the sizes (capacity) of the two survivor spaces, the Eden space and the old generation, all in KB.

3. Check that S0C and S1C have values of 10000 or higher.

4. Check that EC has a size of between 20 percent and 50 percent of OC.

How it works…

jstat is a JVM tool that can be used to view a number of runtime statistics regarding the JVM. More detail on the JVM and its memory layouts is available in the recipes in Chapter 5, JVM Garbage Collection Tuning. The option -gc prints the 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).

What we are looking for are problems caused by the new generation memory spaces (Eden and the two survivor spaces) having capacities that are too small. This will cause garbage collection to occur more frequently than necessary, resulting in poor performance. Due to their nature, SOA Suite applications usually involve a lot of object allocation, but many of these objects generally do not last very long (the duration of a request), so they can be collected while they are still in the Eden or one of the survivor spaces. For this reason, we generally want a SOA Suite application to have an Eden size that is between 10 percent to 33 percent of the total heap size. From our experience, this is a good starting point for an Eden space that needs to cope with lots of short-lived objects. The survivor spaces should be large enough to hold the objects generated by one or two large requests, and we have found that values smaller than 10 MB (around 10000 in jstat) can cause problems.

There's more…

If you have set the new size (or new ratio) and survivor ratio values on the command line, then the values you see in the output of jstat should match those you specified.

See also

• The Setting the survivor ratio and Setting the JVM new size recipe in Chapter 5, JVM Garbage Collection Tuning