That is generally an expected trade off when using the new collectors - perhaps 
a 15% hit to throughput due to locking in concurrent compaction but better 
latency with the shorter pauses.

The last I saw, for smaller heaps, G1 generally wins - better throughput and 
latency that’s just as good.

For larger heaps, if memory is not a constraint, the new collectors win.

If memory is a constraint, you pay for the better latency with throughput with 
the new collectors.

G1 remains a good default generally.

[Mark Miller - Chat @ 
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=1deyla)  
[1deyla]

On January 8, 2022 at 2:33 GMT, Shawn Heisey <[email protected]> wrote:

On 1/6/2022 2:03 PM, David Smiley wrote:
> The new Shenandoah GC looks exciting but may not be sufficiently ready
> for us to recommend (if I recall from a recent user who reported a
> problem with it) -- and that's okay.

I've done some experiments with Shenandoah and ZGC. My index is tiny,
155297 docs and a total index size of 644.22MB. I'm running it with a
max heap of 512MB.

When I uploaded the GC logs to gceasy, the newer collectors showed much
smaller pauses than G1, and more collections. I think the overall pause
time is significantly smaller, but throughput took a hit. It was a
larger impact than I imagined. Last time I tested it, a full rebuild of
the index took about 8 minutes with G1, and over 9 minutes with the
newer collectors. That index is built and used by my dovecot install.
There's pretty much no query activity on my system, so I used the full
index rebuild to exercise it.

I had a remote co-conspirator on this testing. On that user's index,
their reindex procedure failed to complete at all with the newer
collectors, but it did work with G1. I did not get any details about
how it failed, but I know that their testing and mine were done with
OpenJDK 11.

I was going to do some additional testing with OpenJDK 17.0.1, but I
found that when I tried to start Solr with Shenandoah, it has the
following in the console log:

Error occurred during initialization of VM
Option -XX:+UseShenandoahGC not supported

This is very weird, because I saw an article about sub-millisecond
pauses using OpenJDK 17 and Shenandoah. Unless Oracle has decided to
pull Shenandoah completely in-house and not make it available in OpenJDK
any more.

Thanks,
Shawn

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to