G1gc compaction algorithm

[Martin Makundi]

>
>
> 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.
>

I have tried 16m and 32m they both result in worse full gc behavior.


>
> 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.
>

XX:G1HeapWastePercent=0  seems to work, however.


>
> 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.
>

Is this adjustable, I did not notice any parameters affecting this 10%
threshold?

**
Martin

>
>  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>:
>
>> 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>:
>>
>>  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>:
>>>
>>>
>>>>  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/20140724/518a69ae/attachment.html>