Tuning ShenandoahGC with 420 GB heaps

[Jeroen Borgers]

Op di 5 mrt. 2019 om 12:20 schreef Aleksey Shipilev <shade at redhat.com>:

> On 3/5/19 10:51 AM, Jeroen Borgers wrote:
> > Thanks for your remarks. In addition to Edwins findings:
> > 1.1 AlwaysPreTouch seems to be on while reported as off, as shown in
> 'ps' and in logfile it says
> > (line 12:)
>
> Right. Sorry, my bad, that's Shenandoah reverting dropping AlwaysPreTouch
> and enabling
> ShenandoahAlwaysPretouch specifically. It needs to be that way to avoid
> hitting serial pretouch code
> that would wreck up NUMA interleaving.
>

Ok, good to know.


>
> > 3. Right, sudden high allocation rates are a problem. Getting more
> memory will take time. We might
> > be able to throttle the load somewhat.
>
> Yes, either throttle the load (for example, beef up pacing threshold), or
> maybe beef up the
> ConcGCThreads?
>
> We hope we can throttle the system that puts sudden load on our
application. Beefing up the ConcGCThreads might also be an option, although
we are almost at 100% CPU with high load. Application can progress slower
and lose max 16 ms on 30 ms by getting less CPU time, so we might try e.g.
24 or 32.


> > Like my colleague found, (transparent) huge pages do not seem to be
> utilized fully. I see in the log
> > file:
> > Memory: 4k page, physical 528157524k(460445396k free), swap
> 2097148k(1463356k free)
> > and on line 12:
> > Parallel pretouch 13440 regions with 2097152 byte pages
> > So it seems to use both 4kB and 2MB pages. The latter area is only 26 GB.
> > We don't understand this nor how to solve it. Suggestions very welcome.
>
> This is Shenandoah bug! Argh. Tracked here:
>   https://bugs.openjdk.java.net/browse/JDK-8220153
>
> Ah, good finding! And I see your patch solves it, right? When will this be
available?


> -Aleksey
>
>
-Jeroen