G1gc compaction algorithm

[Yu Zhang]

Martin,

I took a look at your 2nd gc log.

Most of the Humongous objects are of 2M, some goes up to 14M.  Can you 
try to set G1HeapRegionSize=16m?  This will get rid of most of humongous 
allocations.  Plus the RS related operations are very long.  Having less 
RSet might help.

Considering the heap usage after full gc is 17g, 
-XX:G1HeapWastePercent=0 is not appropriate.  This should be ~50.
The reason you run into full gc, is a lot of humongous allocation 
happened at that time, while the heap used is ~21g.

There are other tunings we can try, but I think those 2 should give 
better results.

Comments to your questions inlined.

Thanks,
Jenny

On 7/23/2014 8:01 AM, Martin Makundi wrote:
> 1. Log says "recent GC overhead higher than threshold after GC, recent 
> GC overhead: 13.94 %, threshold: 10.00 %" what is that 10% threshold 
> how can it be changed and what will it affect?
G1 uses this to decide when to expand the heap.  It means when the gc 
pause time is over 10% of the application time, then we need to expand 
the heap.
>
> 2. Today I changed -XX:G1HeapWastePercent=0 and didn't get any Full 
> GC:s. I assume this is needed to keep heap clean for those random 
> humongous allocations...
Please see my comments above.
>
> **
> Martin
>
>
> 2014-07-22 18:11 GMT+03:00 Martin Makundi 
> <martin.makundi at koodaripalvelut.com 
> <mailto:martin.makundi at koodaripalvelut.com>>:
>
>     Hi!
>
>     Here is the most recent attempt, we
>     increased GCPauseIntervalMillis to 10000 so that 10% will be a
>     longer time for doing mixed sets. However, we still seem to get a
>     Full GC at "[Full GC 20G->17G(30G), 60.0458620 secs]" due to
>     humongous allocations.
>
>     Any suggestions how to mitigate the Full GC? Here is the full log
>     with parameters:
>
>     http://81.22.250.165/log
>
>     **
>     Martin
>
>
>     2014-07-19 5:38 GMT+03:00 Martin Makundi
>     <martin.makundi at koodaripalvelut.com
>     <mailto:martin.makundi at koodaripalvelut.com>>:
>
>         BTW: We have 16 cores and we probably need 4 for serving web
>         users, is there a way we can utilize more efficiently the
>         excess resources towards gc while keeping user experienced
>         pause at minimum?
>
>
>         2014-07-17 22:21 GMT+03:00 Martin Makundi
>         <martin.makundi at koodaripalvelut.com
>         <mailto:martin.makundi at koodaripalvelut.com>>:
>
>
>                 There are 3 factors: MaxGCPauseMilli,
>                 MixedGCCountTarget, G1OldCSetRegionThresholdPercent
>
>                 The candidate regions is calculated by some algorithm.
>                 minimum regions = (candidate regions)/MixedGCCountTarget
>                 maximum regions = (heap regions)*
>                 G1OldCSetRegionThresholdPercent
>
>
>                 If the estimated mixed gc time is < MaxGCPauseMilli,
>                 g1 will try to add the candidate regions to cset while
>                 keeping the estimated time below MaxGCPauseMilli, as
>                 long as it is less than maximum regions, and
>                 reclaimable percentage higher than the waste limit.
>                 If the estimated mixed gc time is > MaxGCPauseMilli,
>                 g1 will add minimum regions to cset.
>
>
>             What's the science behind these equations (in short) or
>             are they purely ad-hoc?
>
>             **
>             Martin
>
>
>                 In your case, MaxGCPauseMilli is low and
>                 MixedGCCountTarget is 80. So it can only add 2 when
>                 the estimated time > MaxGCPauseMilli
>
>                 Thanks,
>                 Jenny
>
>                 On 7/16/2014 9:14 PM, Martin Makundi wrote:
>>                 > This is a diagnostic parameter, you need to apply with
>>                 > -XX:+UnlockDiagnosticVMOptions
>>                 -XX:+G1PrintRegionLivenessInfo
>>
>>                 Thanks, will try that.
>>
>>                     It will first add old regions if the estimated
>>                     time is under the MaxGCPauseMilli. If the
>>                     estimated time is higher than MaxGCPauseMilli, it
>>                     will add the minimum decided by
>>                     #candidate-regions/MixedGCCountTarget. If you set
>>                     MixedGCCountTarget too high, the minimum will be
>>                     too low. In your case, it is 2.
>>
>>
>>                 Hmm.. what is the logic behind this
>>                 candidate-regions/MixedGCCountTarget? Is there no way
>>                 to tell the gc to estimate the max number of regions
>>                 it could maybe achieve in the time available and do
>>                 that instead of 2?
>>
>>                 **
>>                 Martin
>>
>>                     Thanks,
>>                     Jenny
>>
>>                     On 7/16/2014 6:46 PM, Martin Makundi wrote:
>>>
>>>                         2. For most of the time, eden size is 1.4g,
>>>                         survivor 150m, the rest is old gen.  I am
>>>                         not sure how much of the old gen is used for
>>>                         humongous allocations. But it seems there
>>>                         are some tunings you can try to help mixed gc:
>>>                           - old regions added to cset is 2-14 for
>>>                         mixed gc.  Most of the time the reason is
>>>                         'predicted time too high'.  You can try
>>>                         either increase -XX:MaxGCPauseMillis to a
>>>                         higher value, or decrease
>>>                         -XX:G1MixedGCCountTarget (currently it is
>>>                         80) so that more old regions can be added.
>>>
>>>
>>>                     Does it attempt to do any mixed gc if it cannot
>>>                     do all G1MixedGCCountTarget or is the
>>>                     value G1MixedGCCountTarget just an upper limit?
>>>                     If it just is an upper limit we could keep it at
>>>                     80 or higher?
>>
>>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140723/467f08de/attachment-0001.html>