There have been no objections after 9 days. I'll commit these changes also to 5.0
On Tue, 11 Feb 2025 at 11:16, Jon Haddad <j...@rustyrazorblade.com> wrote: > +1 to putting it in 5.0 > > > On Tue, Feb 11, 2025 at 2:10 AM Mick Semb Wever <m...@apache.org> wrote: > >> Any objections to making the following changes also to 5.0 ? >> >> CASSANDRA-20296 proposes the following changes: >> >> 1. G1 to by default use `-XX:G1NewSizePercent=50` to floor the young >> generation's size to 50% of the heap. (We know in production this can >> often be raised to 66% for optimal performance.) >> >> 2. When using G1, default set `-XX:ParallelGCThreads` and >> `-XX:ConcGCThreads` to the number of system cpu cores. (Existing >> settings are honoured.) >> >> 3. The auto-generated heap size is now half the server's physical RAM, >> capped at 16G for CMS and 31G for G1. This simplifies, and makes more >> appropriate, the previous algorithm. Like before this is only used if >> MAX_HEAP_SIZE or -Xmx hasn't been set. >> >> 4. Increase MaxTenuringThreshold from 1 to 2. Plenty of evidence now >> showing it has no negatives (over values of zero or one), but can >> sometimes have significant benefits in keeping objects in the young >> generation. While values above 2 don't have any noticeable benefit. >> >> 5. Default set CASSANDRA_HEAPDUMP_DIR to $CASSANDRA_LOG_DIR, to avoid >> hprof filling up unexpected disk volumes. Assumption here is that the >> logs directory is large enough to handle these dumps, and/or operators >> are monitoring these directories more than other randon/unknown >> directories. Existing values of CASSANDRA_HEAPDUMP_DIR are honoured. >> >> >> As can be seen, these changes are only going to impact those users >> that haven't set any of these flags. And a number of the defaults are >> wildly bad. The only question I have is how this might impact the dev >> experience on local machines where the ram is already used up. (It >> would be a fail-fast and the dev would have to set a lower >> MAX_HEAP_SIZE, which I think is trivial compared to the benefits >> here.) >> >
