On 1/13/23 05:50, Mick Semb Wever wrote:
Thanks for the support Brad, you're definitely not alone. Alas the
project works in a consensus model, i.e. off the objections made - which
have been all sound. A good compromise has been offered that I will move
forward on, and I'll also update the
> *+1* to changing to G1 on trunk for 5.0 and 4.1.1. We have over a
> thousand clusters and over 10K nodes running on J8 and 11 with G1GC and
> memory management is excellent.
>
Thanks for the support Brad, you're definitely not alone. Alas the project
works in a consensus model, i.e. off the
*+1* to changing to G1 on trunk for 5.0 and 4.1.1. We have over a thousand
clusters and over 10K nodes running on J8 and 11 with G1GC and memory
management is excellent. Excellent. Two observations: first we
reverted MaxGCPauseMillis=200,
which is the JVM default. Cassandra's
same with David Capwell，+1 on updating NEWS in 4.1.x and really change in
4.x /5.0
David Capwell 于2023年1月13日 周五上午3:11写道：
> I am cool with updating NEWS in 4.1.1 to recommend the change and change
> it in 4.2/5.0
>
>
> On Jan 12, 2023, at 10:56 AM, Josh McKenzie wrote:
>
> Potential compromise:
I am cool with updating NEWS in 4.1.1 to recommend the change and change it in
4.2/5.0
> On Jan 12, 2023, at 10:56 AM, Josh McKenzie wrote:
>
> Potential compromise: We change it in trunk, and we NEWS.txt in the minor
> about that change in trunk, why, and recommend users consider qualifying
Potential compromise: We change it in trunk, and we NEWS.txt in the minor about
that change in trunk, why, and recommend users consider qualifying the same
change on their 4.1 release.
In case it's not clear from me:
+1 to changing on trunk for 5.0 here
-1 to changing on minor release given how
I tend to agree with Aleksey's sentiment. Why do we need to change the
default in a minor release if we already provide G1 options for users that
want to opt-in?
On Thu, Jan 12, 2023 at 9:46 AM Aleksey Yeshchenko
wrote:
> Switching a major default in a minor release is way worse than doing it
Switching a major default in a minor release is way worse than doing it in a GA
- less notice and visibility, many folks don’t even read minor version NEWS.txt
before upgrading.
Trunk is fine by me though.
> On 12 Jan 2023, at 13:14, Mick Semb Wever wrote:
>
>> Ok, wrt G1 default, this is
> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
>
> We can revisit it for 4.1.x
>
> We have a lot of voices here adamantly positive for it, and those of us that
> have done the performance testing over the years know why. But being called
> to prove it is totally valid, if you have data
On Thu, Nov 17, 2022 at 2:01 PM Josh McKenzie wrote:
> 3) Expert: Leave me alone. I tune my own GC
This is increasingly not a thing. I haven't looked at ZGC, but G1 and
Shenandoah provide a lot of knobs...that the collector will happily
ignore if it decides it knows better :)
--
I wouldn't recommend Shenandoah or ZGC, period. They're not designed
for the kind of workload you'll typically see running a database (high
throughput of objects that don't tenure) and both will fall over in
interesting ways under high allocation rate. GenShen is intended to
combine the
On Thu, Nov 17, 2022 at 12:47 PM J. D. Jordan
wrote:
> -1 on providing a bunch of choices and forcing users to pick one. We
> should have a default and it should be “good enough” for most people. The
> people who want to dig in and try other gc settings can still do it, and we
> could provide
> -1 on providing a bunch of choices and forcing users to pick one. We should
> have a default and it should be “good enough” for most people.
These are 2 different things (providing choices and whether we provide a
default).
Sounds like you're against both not having a default *and* providing
-1 on providing a bunch of choices and forcing users to pick one. We should
have a default and it should be “good enough” for most people. The people who
want to dig in and try other gc settings can still do it, and we could provide
them some profiles to start from, but there needs to be a
It seems like this is a choice most users might not know how to make?
On Thu, Nov 17, 2022 at 7:06 AM Josh McKenzie wrote:
>
> Have we ever discussed including multiple profiles that are simple to swap
> between and documented for their tested / intended use cases?
>
> Then the burden of having
Jon, thanks for flagging that I didn't get a reply to your question on the thread.My main point in this thread is that I don't
think post-beta is an appropriate time for a major prop change like this in the release cycle. Ideally at this point in the
release cycle, major contributors and large
I'm surprised we released 4.0 without changing the default to G1 given
that many Cassandra deployments have changed the project's default
because it is incorrect. I know that 7486 broke a user 7 years ago,
but I think we have had a ton of testing since then in the community
to build our
On Thu, Nov 17, 2022 at 9:06 AM Josh McKenzie wrote:
>
> Arguably we could take it a step further and not actually allow a C* node to
> startup without pointing to one of the config files from your primary config,
> and provide a clean mechanism to integrate that selection on headless
>
Have we ever discussed including multiple profiles that are simple to swap
between and documented for their tested / intended use cases?
Then the burden of having a “sane” default for the wild variance of workloads
people use it for would be somewhat mitigated. Sure, there’s always going to be
I noticed nobody answered my actual question - what would it take for you to be
comfortable?
It seems that the need to do a release is now more important than the best
interests of the new user's experience - despite having plenty of *production*
experience showing that what we ship isn't
Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
We can revisit it for 4.1.x
We have a lot of voices here adamantly positive for it, and those of us
that have done the performance testing over the years know why. But being
called to prove it is totally valid, if you have data to any such
We have precedent for changing defaults that have near-universal positive
impact in patchlevel releases, yep.
disk_access_mode: auto -> mmap_index_only comes to mind.
- Scott
> On Nov 16, 2022, at 6:49 PM, Derek Chen-Becker wrote:
>
> I'm fine with not including G1 in 4.1, but would we
I'm fine with not including G1 in 4.1, but would we consider inclusion
for 4.1.X down the road once validation has been done?
Derek
On Wed, Nov 16, 2022 at 4:39 PM David Capwell wrote:
>
> Getting poked in Slack to be more explicit in this thread…
>
> Switching to G1 on trunk, +1
> Switching
I share David and Aleksey’s views on this.
We shouldn’t make major defaults changes right before RC. Might be worth adding
a release note recommending users try them, and that they may become default in
a future release though.
— Scott
> On Nov 16, 2022, at 3:38 PM, David Capwell wrote:
>
>
Getting poked in Slack to be more explicit in this thread…
Switching to G1 on trunk, +1
Switching to G1 on 4.1, -1. 4.1 is about to be released and this isn’t a bug
fix but a perf improvement ticket and as such should go through validation that
the perf improvements are seen, there is not
Heap -+1 for G1 in trunk+0 for G1 in 4.1 - I think it’s worthwhile and fairly well tested but I understand pushback against changing this so late in the game.Memtable --1 for off heap in 4.1. I think this needs more testing and isn’t something to change at the last minute.+1 for running
To clarify: -0 here on G1 as default for 4.1 as well; I'd like us to prioritize
digging into G1's behavior on small heaps vs. CMS w/our default tuning sooner
rather than later. With that info I'd likely be a strong +1 on the shift.
-1 on switching to offheap_objects for 4.1 RC; again, think
All right. I’ll clarify then.
-0 on switching the default to G1 *this late* just before RC1.
-1 on switching the default offheap_objects *for 4.1 RC1*, but all for it in
principle, for 4.2, after we run some more test and resolve the concerns raised
by Jeff.
Let’s please try to avoid this kind
For the record, I'm +100 on G1. Take it with whatever sized grain of
salt you think appropriate for a relative newcomer to the list, but
I've spent my last 7-8 years dealing with the intersection of
high-throughput, low latency systems and their interaction with GC and
in my personal experience G1
I'm curious what it would take for folks to be OK with merging this into 4.1?
How much additional time would you want to feel comfortable?
I should probably have been a little more vigorous in my +1 of Mick's PR. For
a little background - I worked on several hundred clusters while at TLP,
+1 to switching to G1 as well. Most production clusters I've seen are
typically running with a heap size of 16 GB or higher which works well with
G1.
I agree with Elliott's comment; I think this change should go into 4.1
onwards (i.e. no change to the default JVM settings in 4.0).
On Fri, 11 Nov
>
> In case of GC, reasonably extensive performance testing should be the
> expectations. Potentially revisiting some of the G1 params for the 4.1
> reality - quite a lot has changed since those optional defaults where
> picked.
>
I've put our battle-tested g1 opts (from consultants at TLP and
I'll withdraw my comment about friendliness of g1 vs cms. I think it's too
late to sneak it in, but wouldn't object formally.
offheap_objects is way too late to change given we shipped the alpha in May
and there are known, long lived bugs that multiple users have reported and
wouldn't have been
+1 to switching to G1.
No opinion about offheap objects.
On 2022/11/09 19:22:08 Mick Semb Wever wrote:
> Any objections to making these changes, at the very last minute, for
> 4.1-rc1 ?
> This is CASSANDRA-12029 and CASSANDRA-7486
>
> Provided we figure out patches for them in the next day
I assume not with 4.0/4.1 though.
It might be a better default than CMS, but switching a major default like this
(an memtable allocation) is not something that should be snuck in at the very
last moment.
In case of GC, reasonably extensive performance testing should be the
expectations.
>From a user PoV, I'd call G1 drastically friendlier than CMS in that it
tends to be well-behaved under a variety of workloads and heap sizes right
out of the box without the kind of dark-art tuning and overnight surprises
you get with CMS. Granted the smallest heap I have now is 2GB, but that's
fwiw, the "CMS is friendlier for small heaps with C*" conclusion may no longer
be accurate; a lot of work has gone into G1 since the last time we've covered
the topic as a project. Nevermind the changes in C*.
Lots of moving targets.
On Wed, Nov 9, 2022, at 6:13 PM, Brad wrote:
> The default
The default garbage collector in Java 11 is G1*. *It's designed to be
self-tuning, so I'd call it friendly. We have run Java 8 and 11 on G1 in
production on all of our 1,000+ clusters for several years.
I'd agree with Jeremiah that it's worth changing in trunk at the very least
and consider
> Can you define "friendlier" in the context of CMS?
Friendlier to small heaps, to Jeff's point about it being much less
friendly to them.
There's a lot of work that's gone into G1 to the point where for
almost all workloads it will perform better than CMS. However, there
are almost no knobs to tune (most G1 params are "advisory" and G1 will
happily ignore them if it wants to), so there may not be a great
replacement if people are
If CMS is gone, is there a friendlier alternative to G1?
On Wed, Nov 9, 2022 at 3:53 PM Josh McKenzie wrote:
>
> My recollection (and brief sleuthing now) surfaces: we've gone back and forth
> on the G1 vs. CMS debate over the years and I think we settled on "it all
> depends on your
My recollection (and brief sleuthing now) surfaces: we've gone back and forth
on the G1 vs. CMS debate over the years and I think we settled on "it all
depends on your environment, workload, and you need to tune it anyway. It might
be worth having a 'default' mode that selects one of the two
G1 you can argue for with the changes in the JDK, though it's MUCH less
friendly to small heaps (e.g. probably our default simple user).
Offheap memtables are different though. If someone wants to attest that
offheap_objects get the same level of rigorous testing as the existing
default, that'd
At DataStax we’ve been shipping those optional G1 settings as the default for
many years now, so I am +1 to at the very least making the change in trunk, but
really I would think it fine to make it back in 4.0 and 4.1 as well.
-Jeremiah
> On Nov 9, 2022, at 1:32 PM, David Capwell wrote:
>
>
CASSANDRA-12029/CASSANDRA-7486 I am not in favor of doing for 4.1, we spend
time validating the current settings, so changing at the last minute adds risk;
so rather push that to 4.2/5.0
> On Nov 9, 2022, at 11:25 AM, Brandon Williams wrote:
>
> CMS was deprecated in JDK 9, I don't see a
CMS was deprecated in JDK 9, I don't see a good reason to follow it
until it's dying breath, and we already have G1 ready in the jvm
options files so this should be an easy switch, +1.
Kind Regards,
Brandon
On Wed, Nov 9, 2022 at 1:22 PM Mick Semb Wever wrote:
>
> Any objections to making these
Any objections to making these changes, at the very last minute, for
4.1-rc1 ?
This is CASSANDRA-12029 and CASSANDRA-7486
Provided we figure out patches for them in the next day or two.
47 matches
Mail list logo
