Rare very big pause
Kirill A. Korinsky
kirill at korins.ky
Tue Dec 19 15:35:23 UTC 2017
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
>
More information about the shenandoah-dev
mailing list