> we had an awful performance/throughput experience with 3.x coming from 2.1.
> 3.11 is simply a memory hog, if you are using batch statements on the client
> side. If so, you are likely affected by
> https://issues.apache.org/jira/browse/CASSANDRA-16201
>
Confirming what Thomas writes, hea
From: Leon Zaruvinsky
Sent: Wednesday, October 28, 2020 5:21 AM
To: user@cassandra.apache.org
Subject: Re: GC pauses way up after single node Cassandra 2.2 -> 3.11 binary
upgrade
Our JVM options are unchanged between 2.2 and 3.11
For the sake of clarity, do you mean:
(a) you
> Our JVM options are unchanged between 2.2 and 3.11
>>
>
> For the sake of clarity, do you mean:
> (a) you're using the default JVM options in 3.11 and it's different to the
> options you had in 2.2?
> (b) you've copied the same JVM options you had in 2.2 to 3.11?
>
(b), which are the default opt
>
> Our JVM options are unchanged between 2.2 and 3.11
>
For the sake of clarity, do you mean:
(a) you're using the default JVM options in 3.11 and it's different to the
options you had in 2.2?
(b) you've copied the same JVM options you had in 2.2 to 3.11?
The distinction is important because at
Thanks Erick.
Our JVM options are unchanged between 2.2 and 3.11, and we have disk access
mode set to standard. Generally we’ve maintained all configuration between
the two versions.
Read throughput (rate, bytes read/range scanned, etc.) seems fairly
consistent before and after the upgrade ac
I haven't seen this specific behaviour in the past but things that I would
look at are:
- JVM options which differ between 3.11 defaults and what you have
configured in 2.2
- review your monitoring and check read throughput on the upgraded node
as compared to 2.2 nodes
- possibly no
On Wed, 28 Oct 2020 at 14:41, Rich Hawley wrote:
> unsubscribe
>
You need to email user-unsubscr...@cassandra.apache.org to unsubscribe from
the list. Cheers!
unsubscribe
On Tue, Oct 27, 2020 at 11:40 PM Leon Zaruvinsky
wrote:
> Hi,
>
> I'm attempting an upgrade of Cassandra 2.2.18 to 3.11.6, but had to abort
> because of major performance issues associated with GC pauses.
>
> Details:
> 3 node cluster, RF 3, 1 DC
> ~2TB data per node
> Heap Size: 12G
