Meaningless Drivel is fun!
The moose likes Performance and the fly likes Verbose GC analysis Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Verbose GC analysis" Watch "Verbose GC analysis" New topic

Verbose GC analysis

Ashish Gauswami

Joined: Aug 20, 2008
Posts: 22
Hi all,

For one of our application which is experiencing performance issues, I have requested heap size increase, and the infrastructure guy denied it by giving me following GC analysis report. He turned on -verbosegc and generated report using some tool.

Mean garbage collection pause (ms) 198
Proportion of time spent in garbage collection pauses (%) 0.38
Number of collections 34476
Largest memory request (bytes) 1923280
Mean interval between collections (minutes) 0.87
Proportion of time spent unpaused (%) 99.6
Allocation failure count 34476
Forced collection count 0
GC Mode optthruput
Mean heap unusable due to fragmentation (MB) 0.77
Concurrent collection count 0
Full collections 0
Total amount tenured (bytes) 1392678
Rate of garbage collection 26.391 MB/minutes

The current heap size is Max 128MB. Please help me understand above terms and advice me if he is correct based on above analysis.


SCWCD - Preparing, SCJP - 86%
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Please explain the performance issues and also explain why you requested a heap size increase.
Ashish Gauswami

Joined: Aug 20, 2008
Posts: 22
Performance issue is application slowness. I have noticed OutofMemory errors in the native_stderr.log file in last few months. Also JVM tried to throw heap dump at the time of OutOfMemory error. Because of OutOfMemory errors I requested heap size increase.

Thanks for the quick response.

Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Thank you. OutofMemory problems are a real problem. They typically stem from a problem in the application's design, e.g memory leakage. A request for a heap size increase will not repair the potential design flaw. In all cases, increasing memory needs to be tested. In some cases, a memory increase will negatively effect the application and make the performance worse than what it is today. Thorough regression testing is required.

The better option is to locate the design flaw(s) and find out exactly what is causing the Outof Memory errors. Once you learn what the true problem is, then you can figure out if you can repair it or go forward with your request for more memory in the hopes that it might help.

Good luck!
Fran├žois Mercier

Joined: Jan 12, 2007
Posts: 4
As you have IBM heapdump available, you can analyse how the memory is retained by using MAT with the IBM plug-in if your jvm is IBM JDK 1.4.2 SR12, 5.0 SR8a and 6.0 SR2; otherwise use HeapAnalyzer
Kees Jan Koster
JavaMonitor Support

Joined: Mar 31, 2009
Posts: 251
Dear All,

While I agree with the premise that many memory errors stem from design flaws, I also think that 128MB heap is very little for a serious production machine.

A simple static analysis of the GC so far does not say all that much. This is probably averaged over a long time skewing the analysis so that the GC seems to be idling. If this is an office hours application and the night is taken into the report, the report is useless.

Ashish, what would help is for you to post the actual OOME error. The error message lets us know what type of memory was needed.

Java-monitor, JVM monitoring made easy <- right here on Java Ranch
I agree. Here's the link:
subject: Verbose GC analysis
It's not a secret anymore!