Upgrade from 11 to 17 leads to busy CPU when idle

[Peter Karich]

Hi StefanJ,

Thanks a lot for pointing this issue out! This seems to be the case here.

Unfortunately reducing this ZFragmentationLimit to 10 (or even 5) did
not help in my case. (Yes, this large amount of read-only data is mostly
primitive arrays and likely compact already)

It is not a big problem for us now as we solve this differently, but I
can imagine that this use case is not that seldom like when holding your
entire DB in memory and then for operating you need much less memory.

Kind Regards
Peter

On 21.12.22 13:48, Stefan Johansson wrote:
> 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
>>