GCViewer pattern analysis

2019-07-23 03:31发布

问题:

Is there any tutorial on GCViewer pattern? I am having an issue where GC logs chart is formed like so but can't figure out if it's a Memory Leak issue or it's just merely need more memory. Can anyone please help me out?

From the log, it showed error " ERROR - java.lang.OutOfMemoryError: GC overhead limit exceeded" Thanks.

回答1:

In order to figure out whether there is memory leak, having a GC chart is not enough. Basically there are two strategies:

  1. Memory Leak Detector: One very good tool is to use Oracle JRockit Mission Control. It's memory leak detector allows you to count number of instances of specific classes. By connecting your memory detector to a running JVM, you can monitor how that number changes overtime. There you should see whether there is memory leaked. A sample of the tool showing these numbers can be found at http://docs.oracle.com/cd/E11035_01/jrockit/intro/wwimages/memleak3.gif.
  2. Heap Dump Analysis: One commonly used tools is MAT from eclipse. It is an Eclipse based application, used to analyze a heap dump of your JVM. You can take a heap dump anytime using jmap provided as part of JDK. Or, alternatively, you can wait for the JVM to dump a file when an OOM occurs. By analyzing a heap dump, MAT should give you a reasonable suspect what is leaking. You can also see clearly how many objects (application classes or library classes) are created and the relationships between them. From this picture, and your knowledge of the application behaviour, you should be able to find out which part of your application goes wrong.

Generally speaking, the first approach is easier and more intuitive for both developers and administrators. The second requires more knowledge of the JVM and heap. Moreover, the first one can be used in production system as JRockit Mission Control has low overhead in production JVM.