Upgrade from 11 to 17 leads to busy CPU when idle

[Stefan Johansson]

Hi Peter,

The reason for the "High Usage" GCs is a heuristic rule added in JDK 13. 
See https://bugs.openjdk.org/browse/JDK-8224185 for some details. This 
rule will kick in when the free heap space is below 5%. According to the 
logs, the usage is around 98% in your use case. This is, as you say, 
probably a fairly uncommon case. Increasing -Xmx will push your usage 
down below the threshold and thus avoid this type of collections running 
back to back.

To push the usage down you could try setting -XX:ZFragmentationLimit=10 
(default is 25). A lower limit will try to compact the heap even more, 
but this will only help if your large amount of read only data is not 
already very compact.

Hope this helps,
StefanJ


On 2022-12-20 12:04, Peter Karich wrote:
> Hi,
> 
> I'm sorry in advanced if this is the wrong mailing list, but I think my
> issue might be related to ZGC.
> 
> The application ran under JDK 11.0.5+10 used -Xmx233g -Xms233g as jvm
> parameters and was running fine and stable on Intel Xeon hardware with
> 256GB RAM and 6 cores. Note that most of the heap for this application
> is static and the application itself is fine with a small amount of
> memory like 3GB.
> 
> When upgrading to JDK 17.0.5+8 we observe that there was a steady load
> (3 cores at 15-25%) although the application received no load. Maybe ZGC
> tries to reduce the static heap somehow? I tried to tune the JVM with
> -XX:+AlwaysPreTouch, -XX:ZFragmentationLimit=80 and/or -XX:-ZProactive
> but I wasn't able to fix this. When using -Xloggc it heavily writes new
> log entries and is frequently running "Garbage Collection (High Usage)".
> See https://gist.github.com/karussell/7b9c2a94d5e86c927778421cead4ffd8
> 
> The only way to fix this was to increase -Xmx to 243g.
> 
> It is surely an unusual use case (large amount of read-only heap and
> only a tiny free space), but requiring now nearly 10GB more RAM seems
> unusual.
> 
> Kind Regards
> Peter
>