Two basic questions on -verbosegc and -XX:+PrintTenuringDistribution

Rainer Jung rainer.jung at kippdata.de
Sun Apr 22 14:00:49 PDT 2012


On 22.04.2012 22:24, Taras Tielkes wrote:
> Hi,
>
> We're using a time-series database to store and aggregate monitoring
> data from our systems, including GC behavior.
>
> I'm thinking of adding two metrics:
> * total allocation (in K per minute)
> * total promotion (in K per minute)
>
> The gc logs are the source for this data, and I'd like to verify that
> my understanding of the numbers is correct.
>
> Here's an example verbosegc line of output (we're running ParNew+CMS):
> [GC 2136581.585: [ParNew:345951K->40960K(368640K), 0.0676780 secs]
> 3608692K->3323692K(5201920K), 0.0680220 secs]
>
> a) The delta between the ParNew "before" and "after" is: 345951K-40960K=304991K
> My understanding is that the 304991K is the total of (collected in
> young gen + promoted to tenured gen)
> Since this number of composed of two things, it's not directly useful by itself.
>
> b) The delta between the overall heap "before" and "after" is:
> 3608692K-3323692K=285000K
> I assume that this is effectively the volume that was collected in
> this ParNew cycle.
> Would it be correct to calculate the total allocation rate of the
> running application (in a given period) from summing the total heap
> deltas (in a given timespan)?
>
> I do realize that it's a "collected kilobytes" metric, but I think
> it's close enough to be used as a "delayed" allocation number,
> especially when looking at a timescale of 10 minutes or more.
> It has the additional convenience of requiring to parse the current
> gc.log line only, and not needing to correlate with the preceding
> ParNew event.
>
> c) I take it that the difference between the two deltas (ParNew delta
> and total heap delta) is effectively the promotion volume?
> In the example above, this would give a promotion volume of
> (345951K-40960K)-(3608692K-3323692K)=19991K
>
> d) When looking at -XX:+PrintTenuringDistribution output, I assume the
> distribution reflects the situation *after* the enclosing ParNew event
> in the log.

Have a look at -XX:+PrintHeapAtGC. This will help you get more precise 
numbers.

Regards,

Rainer



More information about the hotspot-gc-use mailing list