Monitoring Memory Growth in GlassFish

There is an easy way to monitor memory growth in GlassFish. Here's how I do it.....

Issue the following asadmin command which logs GC output to a file called gc.log. This gets created in the path that is provided in the following command.

For Das Instance:

<glassfish_install_dir>/bin/asadmin create-jvm-options --host <host_name> --port <admin_port>
--user <admin_user_name> --passwordfile <admin_password_file>
-- '-Xloggc\\:${com.sun.aas.instanceRoot}/logs/gc.log'

For Cluster Instances:

<glassfish_install_dir>/bin/asadmin create-jvm-options --host <host_name> --port <admin_port>
--user <admin_user_name> --passwordfile <admin_password_file> --target <cluster_name>
-- '-Xloggc\\:${com.sun.aas.instanceRoot}/logs/gc.log'

When the cluster is restarted, gc.log file is created in the logs directory of all the instances in the cluster since that is the location provided in the above command. GC log file will have information about the heap and garbage collection which gets printed at each collection. As long as the server instances are up and running, the gc.log file will have these information printed continuously. When the server is restarted, this log file gets overwritten.

Below are brief explanations on the values displayed in the GC Log File:

1) MINOR Collection

Minor Collection happens when young generation is filled up. Young Generation is the memory pool in which vast majority of objects are allocated and most objects die here, that is they "die young". A young generation that is full of dead objects is collected very quickly.
This is an example of a Minor Collection: 
522481.361: [GC 11183K->3503K(12736K), 0.0193904 secs]
  • 522481.361 => Gives the time in seconds. It tells how long the program has been executing. To convert to hours, it will be 22481.36 / 3600 = 145.13 hrs
  • 11183K => This is the size occupied by live objects in heap before garbage collection.
  • 3503K => This is the size occupied by live objects in heap after garbage collection.
  • (12736K) => This is the committed size of the heap, that is the amount of space usable for java objects without requesting more memory from the operating system.
  • 0.0193904 secs => Time taken by the Garbage collector. In this example, it takes 0.019 seconds to collect objects.
2) MAJOR Collection

Some fraction of the surviving objects from the young generation are moved to the tenured generation during each minor collection. Eventually the tenured generation will fill up and must be collected, resulting in a Major Collection. Here the entire heap is collected. Major Collection usually lasts much longer than minor collections because a significantly larger number of objects are involved.
This is an example of a Major Collection: 
20082.357: [Full GC 24663K->1877K(35072K), 0.3150238 secs]
When Full GC's are continuously seen in the gc.log file, this could be an indication of a memory leak. Sometimes you see this trend in the gc.log file even before you hit an "OutOfMemoryError". Monitoring GC log is helpful in determining a memory leak at a much earlier stage in the Testing Cycle. Another useful technique is to grep for "Full GC" in the gc.log file. If the size occupied by live objects in heap after garbage collection (the number after the arrow) is increasing tremendously during the run, then that will also determine a memory growth.

To detect exactly which object is leaking memory, Configure JProfiler for GlassFish and begin profiling or use Mustang to Profile GlassFish.

Reference Links:
Comments:

Great Blog Meena!!

Posted by Jeanfrancois Arcand on May 23, 2008 at 05:49 AM PDT #

Hi Meena, I learnt how to use GC LOG in your blog. Your writing is very clear and interesting. Thanks Meena !

Posted by Judy Tang on May 30, 2008 at 03:00 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Meena Palani

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today