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

[Aaron Daubman]

Hi Monica,

Thanks for the reply and very helpful analysis - some followup in-line
below:

I'd like to start by noting that by explicitly setting NewRatio, you are
> basically not letting your nursery adaptively grow (upto 80% of heap) or
> shrink (down to 20% of heap) which is needed by G1 to try to meet its pause
> time goal. In your case, it works out OK though.
>

Could you say some more about NewRatio? The setting I used was one out of
several attempts that seemed to do OK - is this best to not set with G1GC?
(what is and isn't adaptive? it seems that even MarkStackSize is on its way
to becoming adaptive?)



> Anyway, here's what I understand from your log -
>
>    - After your first 4 young collections the heap occupancy crosses 45%
>    of 8G (3.6Gs) and hence you see the "initial mark" piggy-backed on the
>    young collection
>       - The time spent in copying here by itself was 1.1sec (on an
>       average) for the 33GC threads
>    - After plotting your heap occupancy and GC Histo, it seems that your
>    heap occupancy stays around 3.5Gs till the first expansion to ~10Gs and
>    then stays at around 4Gs (Note: with this expansion the new heap occupancy
>    limit is around 4.5Gs) and it seems that you are allocating "humongous
>    objects"
>       - The reason being that the next multitude of initial-marks are not
>       showing Eden reaching its full capacity.
>       - And the assumption is that since the heap is near its Marking
>       Threshold limit, the humongous object allocation is triggering the initial
>       mark.
>    - I also spotted some (528 in number)
>    "concurrent-mark-reset-for-overflow" and when I consulted with John
>    Cuthbertson, he mentioned that we should try to increase the MarkStackSize
>    to alleviate that issue.
>
> Would you please point me to more documentation on this, as well as
suggest how to increase it (and to what)?


>
>
> So quick recommendations based on your application "phases" that we see
> from you GC logs -
>
>    1. Increase your InitiatingHeapOccupancyPercent. 70 could be a safe
>    number for you.
>    2. Increase your MarkStackSize.
>
> How / to what? (what are sane limits?)


>
>    1. Print with GC cause enabled (PrintGCCause)**, so that you can
>    understand what's causing all those pauses.
>
> Adding -XX:+PrintGCCause resulted in the JVM failing to launch with this
error:
---snip---
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
---snip---


>
>    1. Also, looking at your command-line, I wanted to quickly highlight
>    that UseBiasedLocking and UseTLAB are probably enabled by default. Also,
>    UseNUMA will have no effect.
>
>
What would be a good way for me to find this out? (e.g. is there an
up-to-date list of flags and defaults for current JDK versions?)

Thanks again!
     Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20121017/57b48265/attachment-0001.html