2

i was comparing two branches of one of our projects for performance, one is much slower than the other. I noticed the GC Run count is higher for one (See graph below).

Runs

More interestingly, the running time is many times higher, much more than can e explained by the extra runs. What would explain the 40%(ish) increase in number of runs increasing the running time by a factor of 6? Larger objects? Too many objects? Also what are some of knobs to tune here and what is there effect? (Some good links are fine as an answer)

Time

Usman Ismail
  • 17,999
  • 14
  • 83
  • 165
  • 1
    This is a very complicated thing to be answered in a forum. In any case you can start by checking if you are creating much more objects than before, how many of them are dying at the first generation and how many are crossing over to the next one and try to figure out if you can create less objects. – Maurício Linhares Jun 13 '12 at 14:38
  • 2
    No one silver bullet to answer this. If you're looking for information about tuning garbage collection: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html – Girish Rao Jun 13 '12 at 14:41
  • Are these minor collectors or full collections? What do you see if you try increasing the new size? – Peter Lawrey Jun 13 '12 at 14:43
  • There were a lot more string objects because of a refactoring. I am now be going to use StringBuilder to take some of that load off. – Usman Ismail Jun 14 '12 at 13:39

1 Answers1

2

Here are some basic guidelines on what you could do to analyze the performance and GC behavior of the two branches/versions of your application:

  1. Evaluate the GC behavior of both applications:
    • Collect the GC logs and compute Live Data Set size, Allocation Rate, Promotion Rate and Total GC time. This should allow you to empirically compare the GC behavior of the two apps.
    • You should compare these GC statistics between the apps, do you see any spikes/differences between the two applications.
    • see here on howto collect these data : Is there a cookbook guide for GC problems?
  2. Collect Class Histograms
    • if you will confirm in the step 1 that there is really a major GC difference, try to collect Class Histograms to see which classes occupy the heap. Compare Histograms between the two apps and see if there are any differences in class types, number of instances. This should help you to identify the culprit.
    • collect Histograms Before/After a FullGC : -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC
    • and also, you collect snapshots jmap -histo $pid anytime during the run. Specially if you see suspicious ResponseTimes/CPU spikes, etc.
  3. Profile the Memory with a Java Profiling tool
    • collect profiles of the two applications and compare,
    • I would recommend jProfiler.

Basic guidelines for performance comparison : To effectively compare the performance, you need to be able to generate the same workload for both versions of your applications, run with some warmup time and then collect the data in a steady phase.

Community
  • 1
  • 1
Aleš
  • 8,896
  • 8
  • 62
  • 107