What should be checked in gc.logs

Question

I know many things about what should be perceived from gc.logs like

• you should check how frequently "Full GC" runs, if it is running frequently then it is sign of problem
• you should also check how much memory "Full GC" is able to reclaim while finishes, if it is not much then again it is sign of problem as it would force "Full GC" to run again
• you should revisit your heap space allocated for java process if "Full GC" runs frequently.

These are some points on which I am working on, I would be interested to know what else should be taken care, when I look at gc logs.

FYI, I have already gone through following threads....

• What does "GC--" in gc.log mean?
• What does "GC--" mean in a java garbage collection log?
• How to analyse and monitor gc.log garbage collector log files from the JVM
• Is gc.log writing asynchronous? safe to put gc.log on NFS mount?

Answer 1

First you need to know what wrong can GC do to your program. Depending on the type of collectors that you use for tenured and old gen contents of GC logs may vary. But all in all the baseline inference that we need to derive from gc logs is mostly concentrated to the following:

• How long are the minor collections taking?
• How long are the major collections taking?
• What is the frequency of minor collections?
• What is the frequency of major collections?
• How much does a minor collection reclaim?
• How much does a major collection reclaim?
• Combinations of the above

Most Program have a very frequent minor collections that claim about 90-95% of heap and pass the rest to Survivor spaces. Subsequent collections clean up survivors by about 80% again and in essence just 2% to 4% of you actual minor collection makes it to old gen and tis cycles keeps on going no matter which Collector you use.

Now the pain areas are when you have hundreds of small sized minor collections per application request or thread and when added up they make a sizable time mostly in double digit seconds. Since in modern collectors minor pass and sweep are not stop the world cases so somethings this is bearable. With Old gen the problems come when collectors run but don't reclaim anything major. e.g: normally a collector runs when the old gen is about 80-85% full. This may be a stop the world episode since new data cannot be saved on heap unless the heap has more space which is probably the case here. So app threads are paused to let GC threads cleanup the space first. but once the collector finishes the heap fill ratio doesn't come down much as it should. A good sizing should reduce your heap by more than 40% in a single go. If it doesn't that means you need more heap to save your long lived objects.

So in essence GC analysis is not a 'do it based of a set of predefined steps' things. Its more of a hti and trial analysis. It more of an experiment were you set the initial sizes and settings and then note or monitor the GC activity and record findings. Then after say 8-10 runs you compare notes and see what works for your app and what doesn't. Its really an interesting hard work to do.