Help processing G1GC logs (visualization tools) - also, mysterious great performance after inexplicable full GC?

[Monica Beckwith]

Thanks! Simone. :) Aaron - Please look at the J1 presentation that 
Simone has linked here (and feel free to ask questions/ provide 
comments). And like Simone mentioned, please send in the GC logs for the 
case where G1 does poorly with "-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps" enabled on the command line. Looking at the GC 
log(s), we can hopefully identify the cause of that major GC (which I am 
assuming to be a Full GC). We should also be able to work on improving 
(or at-least explaining) your response times, but we would like to know 
a) what is your goal, b) what are the important factors (e.g. sizing 
limitations, etc) and c) if you are working off some comparison (e.g. a 
previously tuned garbage collector).

Thank you for trying G1!

-Monica


On 10/16/2012 8:19 AM, Simone Bordet wrote:
> Hi,
>
> On Tue, Oct 16, 2012 at 2:54 PM, Aaron Daubman<daubman at gmail.com>  wrote:
>> Greetings,
>>
>> I recently switched to trying G1GC for several webapps and am trying
>> now to make sense of the GC behavior.
>> I have a few hopefully not-too-newbie questions:
>>
>> 1) Is there any up-to-date documentation on tuning G1GC? (many
>> articles about it seem to be pre-7u4 where there were apparently more
>> experimental flags available for tuning). Also, is this currently the
>> full set of flags available:
>> http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html#G1Options
> Perhaps most up to date information is from the JavaOne sessions just held.
> See in particular:
> https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=7236
> https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=6583
>
>> 4) In one webapp, the constant reason for frequent GCs is listed by
>> VisualVM as "G1: humongous allocation attempt". However, searching to
>> try and figure out what this means results in only a very few bug
>> entries (e.g. 7018286) that do not explain at all what this means, or
>> what the threshold for being declared 'humongous' is - were can I find
>> out more about this reason for minor GC?
> Humongous allocation means an allocation for a large object (a
> "humongous object").
> Normally these are large byte[], or objects that contain large byte[].
>
> In G1, I believe that "humongous" is when the size is greater than
> half a region, which by default are 1 MiB, but not 100% sure.
>
>> 5) I think I am perhaps just missing something given the lack of
>> capability of the current suite of tools, however this one really
>> bothers/intrigues me.
>> One webapp where I switched to G1GC does quite poorly (somewhat
>> inexplicably) for 12 or so hours (in terms of response times). This
>> app has a med/large (16G) heap size, and typically runs at 1/2 to 1/4
>> heap utilization. On occasion, even though overall heap utilization is
>> below 40%, there will occur a (I've only ever seen single) major GC,
>> and, without explanation, the application runs with order-of-magnitude
>> better performance after this (heap utilization remains about 40%
>> after major GC... eden and old commit size go up a small amount,
>> nothing else changes that I can see). What would cause this markedly
>> better performance after a major GC, and how can I dig in to this
>> better?
>> (I am frustrated, since it seems I should be able to figure out what
>> JVM flags to use that would cause performance to be always as good as
>> it is after the mysterious full GC, but I haven't been able to figure
>> anything out so far).
> Please record logs with the flags suggested in the 2 presentations I
> linked above.
> In particular, I use:
> -XX:+PrintGCDetails
> -XX:+PrintGCDateStamps
> -XX:+PrintAdaptiveSizePolicy
>
> Once you have the log, attach it here, and hopefully someone will look at it.
>
> Keep in mind that G1 is still "young" and while it will be the future,
> today it may not be up to par with the other collectors.
>
> Simon

-- 
Oracle <http://www.oracle.com>
Monica Beckwith | Java Performance Engineer
VOIP: +1 512 401 1274 <tel:+1%20512%20401%201274>
Texas
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20121016/9b7675ef/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20121016/9b7675ef/oracle_sig_logo.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green-for-email-sig_0.gif
Type: image/gif
Size: 356 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20121016/9b7675ef/green-for-email-sig_0.gif