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'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

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'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

Re: GC pauses way up after single node Cassandra 2.2 -> 3.11 binary upgrade

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

Re: GC pauses way up after single node Cassandra 2.2 -> 3.11 binary upgrade

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

Re: GC pauses way up after single node Cassandra 2.2 -> 3.11 binary upgrade

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!

Re: GC pauses way up after single node Cassandra 2.2 -> 3.11 binary upgrade

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:

GC pauses way up after single node Cassandra 2.2 -> 3.11 binary upgrade

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 / New Size: 5G I didn't even get very far in the upgrade - I just upgraded a binary

Re: Cassandra timeout during read query

Hi Attlila, We did have larger partitions which are now below 100MB threshold after we ran nodetool repair. And now we do see most of the time, query runs are running successfully but there is a small percentage of query runs which are still failing. Regarding your comment ```considered with

Re: Cassandra 4.0-beta1 available on FreeBSD

Angelo Polo wrote: Cassandra 4.0-beta1 is now available on FreeBSD. By the way I'm runinning a 6 nodes production cluster using 3.11.6 on FreeBSD 12.1/amd64 and I'm very happy about it (thanks Angelo for maintaining the FreeBSD Port!). I hope your 4.0-beta2 patch will be accepted soon (and

Repair shell script

I'd like to set up Cassandra Reaper soon enough, but right now I'm keeping my cluster repaired with the following self-made script. I created it by reading official wiki and some of this ML's messaes, but can anyone confirm I chose the correct options? (i.e. running "repair -pr" in turn on

Re: Anti-entropy repair with a 4 node cluster replication factor 4

If you run full repair then it should be fine, since all the replicas are present on all the nodes. If you are using -pr option then you need to run on all the nodes. On Tue, Oct 27, 2020 at 4:11 PM Fred Al wrote: > Hello! > Running Cassandra 2.2.9 with a 4 node cluster with replication factor

Anti-entropy repair with a 4 node cluster replication factor 4

Hello! Running Cassandra 2.2.9 with a 4 node cluster with replication factor 4. When running anti-entropy repair is it required to run repair on all 4 nodes or is it sufficient to run it on only one node? Since all data is replicated on all nodes i.m.o. only one node would need to be repaired to

RE: migrating driver from 3.4 to 4.9

Thanks Johnny Sent from Mail for Windows 10 From: Johnny Miller Sent: 27 October 2020 08:37 To: user@cassandra.apache.org Subject: Re: migrating driver from 3.4 to 4.9 Manu - one thing

Re: migrating driver from 3.4 to 4.9

Manu - one thing to make sure your aware of is with the latest driver version (4.9) it’s not just about binary compatibility. There has been a removal of certain core features from the driver which if you are using you may find you’ve more work todo then you expected. The ability to route

OOM on ccm with large cluster on a single node

Hi, I'm using ccm to create a cluster of 80 nodes on a physical server with 10 cores and 64GB of ram, but always the 43th node could not start with error: java.lang.OutOfMemoryError: unable to create new native thread apache cassandra 3.11.2 cassandra xmx600M 30GB of memory is still

RE: migrating driver from 3.4 to 4.9

Thanks Erick. I agree that I should considering moving to latest version. Sent from Mail for Windows 10 From: Erick Ramirez Sent: 26 October 2020 22:55 To: