How to check for garbage collection problems in Introscope (heap analysis)

Home > Search > How-to
  by

  1. In the Introscope investigator, select the Metric Browser tab.
  2. Expand SuperDomain > server_hostname > server_type > your_jvm > GC Heap.

By default, Introscope will display data for the last 8 minutes, and update about once every 30 seconds. For this analysis, you will definitely want to toggle of Live, and then select a custom range of about 1 hour. 

 


Saw Tooth Pattern

When garbage collection is working as expected, you would expect to see a sort of saw tooth pattern. In this example, the saw tooth pattern is absolutely ideal. This is not common with an app that is being used. This type of pattern is what you would expect to see when the app has little to no activity.

 

When an app is being used, you should still be able to see a saw tooth pattern. However, the pattern will not be as consistent. This is still OK.

 

What you are looking out for is when the saw tooth pattern becomes erradic. An erradic pattern may be an indication of some issue, such as the JVM moving towards an out of memory situation. When you see an unexpected and inconsistent pattern, check the JVM logs to see if you can spot an issue with the JVM.

 


Garbage Collection Frequency

A complex and popular app will have more frequent garbage collection than a simple and unpopular app, so there isn't a magic interval for how often garbage collection should occur, and how many MB of objects should be removed from the heap. However, generally speaking, if the app is complex and popular, garbage collection once every 10 minutes or so is probably OK, with a removal of about 100 MB of objects.

 

On the other hand, if garbage collection is occurring very often, and only a few MB of objects are being removed by the garbage collector, there are a few possibilites.

  • Large Footprint - An application may simply have a large footprint, meaning that the application is placing a large number of objects in the heap. In this example, the initial heap size is 512 MB, and the average heap usage is near 450 MB, meaning that the application(s) on the JVM are using nearly all of the heap. There is no steady incline, meaning there is not a memory leak. In this example, it probably makes sense to increase the maximum heap size.
  • Code Problem - There may be a problem with the code of the Java app where objects that are no longer needed are not being let go by the app. This would require a review of the code of the Java app to determine what code may be the cause of this problem.

 


Analyze the heap dump

IBMs Heap Analyzer can be used to analyze a heap dump. IBMs Heap Analyzer can be installed as a tool in IBMs Support Assistant Team Server

 

In IBMs Heap Analzyer, select File Open, select the heapdump.phd file, and select Open. The analysis will identify the Java classes that contain objects that are taking up heap space. In this example, the java/lang/Object class is using 27.59% of the heap.

 

A class is a container that contains one or more objects. In this example, there is a class called Dog that contains an object called Puppy with a value of Old Yeller. The programmer that created the application that has classes taking up heap space will need to determine if a code change can be made to the application to reduce the heap space being used by the class.

Public class Dog {
  Public static void main(String []args){
    Puppy myPuppy = new Puppy( "Old Yeller" );
  }
}

 

 



Add a Comment




We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.




Please enter in the box below so that we can be sure you are a human.




Comments