loadrunner How we can determine by seeing GC graph(GC invocation time graph...

  • perf-test.com need your contributions to build up a strong repository of performance engineering resources.

V

Vishwajeet Singh

Guest
How we can determine by seeing GC graph(GC invocation time graph and GC invocation frequency graph) in OEM(oracle tool) that there is GC bottleneck.What is GC performance bottleneck determination criteria?
 
Sort by date Sort by votes
A very broad concept to pin point. On a high level, either your response time or throughput or both will correlate with your GC pauses. In order to understand why it does that, you will need to understand the GC algos. There are sophisticated GC algos which will try to keep this disruptions minimal. For example, CMS GC will try to meet your throughput goal while trying at the same time to meet your response time goal. Both of these are 98% by default. iCMS is much more efficient than CMS. And then if you are using JDK 7u25 and later, the most sophisticated G1 can be used. Starting from JDK 6 and above, ergonomics will try to minimize the effect of GC on your load pattern. But then, you will need to completely understand what your application does and what your requirements are in order to identify GC as bottleneck.
 
Upvote 0 Downvote
@Kranthi Paidi; I ran test for 1 hour and and I got about 100 young generation gc invocation with gc invocation time 0.178sec and 7 old generation with gc invocation time 3 sec occured.Is this data under limit from performance point of view....So I need to know how much gc invocation in an hour is sufficient for better performance.....is there any thumb rule like so to decide no. Of gc invocation to decide better performance
 
Upvote 0 Downvote
@Kranthi Paidi; Thanks for sharing the documents....It's of great importance....Can you let me know what brought you to the conclusion that is GC is fine....Can you provide me any rough data,how much gc invocation in an hour is fine?So that next time I can make conclusion on my own...just asking from learning point of view
 
Upvote 0 Downvote
The total GC time spent is less than 1% of the application time - which seems to be fine with me combined with your first statement "very high response times".. in general it is not uncommon to see 1000s of young GC collections and 100s of old gen collections as long as they are under 1% of the total application time
 
Upvote 0 Downvote
Actually there are 7 old gc in an hour so it accounts 7*3=21sec and 100 young gc i.e 100*.178=17.8 sec.Total 21+17.8=38.8.so 38.8/3600=1.07%.....is coming
 
Upvote 0 Downvote
Ohh...my bad...Even then, i think it should be fine...now that we have a different picture, does the timestamps of "very high txn resp times" correlate with that of GC pauses?
 
Upvote 0 Downvote
3 sec pause is actually bad in some cases...It will be interesting to see what your tenure sizing and heap sizing is and your GC algo
 
Upvote 0 Downvote
Actually we have not drilled down upto there whether timestamp is correlating with gc pauses....we had simple graph feom OEM where we are getting gc counts and gc invocation time...that data which I shared above ....
 
Upvote 0 Downvote
no knowledge of your workload and application and sample time of 1 hour is too less to make a comment on it. On a normal note, it should be fine
 
Upvote 0 Downvote
You must log in or register to reply here.
Top Bottom
Back