ZGC EAB +2 FEEDBACK

[Erik Osterlund]

Hu Evaristo,

Thank you for reporting this! This is very useful information.

I have seen similar patterns when the heap gets squeezed tight, and the minor collections can go a bit bananas while waiting for a major collection to finish. The minor collection policy feels panicked that we are about to cross the specified line, and needs to GC to free up memory. While that is partially true, the trouble is that there is barely any memory available to free up since all the garbage is in the old generation. And by spinning up minor collections, it can steal threads from the major GC which is the one that can actually free up memory.

We will have a look at how to fix this. Stay tuned!

Regards,
/Erik

On 3 Nov 2022, at 11:45, Evaristo José Camarero <evaristojosec at yahoo.es<mailto:evaristojosec at yahoo.es>> wrote:


Hi there,

 First, thanks for the job. I am really excited following your videos, the github repo, mails... I think this will be a game changer, because although ZGC is already there and pauses are great, in some cases extra memory and CPU to run the workload is too high.

 I have been doing some happy testing with Build 20-genzgc+2-20 (2022/10/31) -> No crashes compared with first build.


 I am using Linux 686 (Manjaro with a recent kernel) running on a VBox VM.


 To do the tests, I am using Apache Geode (distributed cache) with 2 servers (one using Gen ZGC and another G1). I run simple test populating the cache. The test is adding entries and the Apache Geode is synchronously replicating information in both servers before answering the client populating the cache.


 - TEST 1: (-Xmx4096m -XX:+UseZGC for server with GenZGC) Using Xmx=4G. Everything looks fine for me.


 - TEST 2: (-Xmx4096m -XX:SoftMaxHeapSize=3500m -XX:+UseZGC for server with GenZGC). Everything looks fine for me until JVM decides to utilize all memory when SoftMaxHeapSize is NOT sustainable anymore. What is strange for me at this point, is that YoungGen is kept extremely small while (around 20MB) and OldGen is basically taking almost all the heap (I would expect once that all memory is utilized then is shared between Young and Old and heuristics will find the right balance). The side effect is that objects are immediately promoted to OldGen because basically there is no room. On the other hand, a huge amount of Minor collections is done (almost not freeing any memory), and obviously Major Collections are also needed to keep application running. I am NOT sure if -XX:SoftMaxHeapSize is expected to be supported in GenZGC. In case the answer is yes, probably something need to be improved to better support the use case (e.g. giving more buffer to youngGen). Maybe you have a different goal in your mind for this setting.


 Just let me know if you need extra information (jconsole pictures, logs...)


 Regards,


 Evaristo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20221103/60ae6ad8/attachment.htm>