Rare very big pause

[Kirill A. Korinsky]

Well, it helps decrease pauses, but it is still about 150-200 ms.

For example:

Concurrent marking triggered. Free: 1718M, Free Threshold: 1720M; Allocated: 1718M, Alloc Threshold: 0M
2017-12-19T16:59:02.785+0000: 3055.494: [Pause Init Mark, 2.553 ms]
2017-12-19T16:59:02.788+0000: 3055.496: [Concurrent marking 4418M->4723M(6144M), 916.628 ms]
2017-12-19T16:59:03.710+0000: 3056.419: [Pause Final MarkTotal Garbage: 3555M
Immediate Garbage: 1374M, 688 regions (41% of total)
Garbage to be collected: 1849M (52% of total), 965 regions
Live objects to be evacuated: 80M
Live/garbage ratio in collected regions: 4%
 4723M->3351M(6144M), 175.951 ms]
2017-12-19T16:59:03.886+0000: 3056.595: [Concurrent evacuation 3352M->3453M(6144M), 71.376 ms]
2017-12-19T16:59:03.959+0000: 3056.667: [Pause Init Update Refs, 0.099 ms]
2017-12-19T16:59:03.959+0000: 3056.667: [Concurrent update references  3453M->3489M(6144M), 578.340 ms]
2017-12-19T16:59:04.538+0000: 3057.246: [Pause Final Update Refs 3489M->1560M(6144M), 2.241 ms]
2017-12-19T16:59:04.540+0000: 3057.249: [Concurrent reset bitmaps 1560M->1560M(6144M), 3.516 ms]
Capacity: 6144M, Peak Occupancy: 4723M, Lowest Free: 1420M, Free Threshold: 1228M
Adjusting free threshold to: 25% (1536M)


--
wbr, Kirill


> On 19 Dec 2017, at 19:35, Kirill A. Korinsky <kirill at korins.ky> wrote:
> 
> Thanks for advice.
> 
> Trying.
> 
> --
> wbr, Kirill
> 
> 
>> On 19 Dec 2017, at 19:25, Aleksey Shipilev <shade at redhat.com> wrote:
>> 
>> On 12/19/2017 04:12 PM, Kirill A. Korinsky wrote:
>>> May you suggest any way to understand where and how much it try to allocate?
>>> 
>>> Because this application shouldn't allocate so big memory and how I can see it from line before it had 245Mb free memory when GC cycle happened.
>>>> Concurrent marking triggered. Free: 245M, Free Threshold: 245M; Allocated: 245M, Alloc Threshold: 0M
>> 
>> I don't think this is application's fault. Your config runs with 4 GB heap. Default settings for
>> "adaptive" heuristics target to maintain 3% of free heap at all times during the cycle. That means
>> 120M. Single application thread may allocate this much in around 20 ms. And concurrent mark takes
>> around a second. So, we have only a razor-thin room for error here. With a small heap like that,
>> even a trivial allocation spike may blow up with Allocation Failure.
>> 
>> I guess Shenandoah's heuristics needs to reserve more on smaller heaps, so that some absolute amount
>> of space was always available. We have patches in queue to make this better. Meanwhile, you may want
>> to adjust these:
>> 
>> experimental(uintx, ShenandoahInitFreeThreshold, 30,                      \
>>              "Initial remaining free threshold for adaptive heuristics")  \
>>         range(0,100)                                                      \
>>                                                                           \
>> experimental(uintx, ShenandoahMinFreeThreshold, 3,                        \
>>              "Minimum remaining free threshold for adaptive heuristics")  \
>>         range(0,100)                                                      \
>>                                                                           \
>> experimental(uintx, ShenandoahMaxFreeThreshold, 70,                       \
>>              "Maximum remaining free threshold for adaptive heuristics")  \
>>         range(0,100)                                                      \
>>                                                                           \
>> 
>> Say, -XX:ShenandoahMinFreeThreshold=20 for your case.
>> 
>> Thanks,
>> -Aleksey
>> 
>