Tuning ShenandoahGC with 420 GB heaps

[Edwin Graven]

Aleksey

Okay so THP is a bug, is there any change it will be possible to use LargePages instead of THP like we do with G1??
If you can use LargePages there won’t be any risk of using swap. 

Edwin

Verstuurd vanaf mijn iPhone

> Op 5 mrt. 2019 om 13:24 heeft Jeroen Borgers <jborgers at jpinpoint.com> het volgende geschreven:
> 
> 
> 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