Re: compaction trigger after every fix interval

There's many things that can trigger a compaction, knowing the type of compaction can help narrow it down. Have you looked at the nodetool compactionstats command output when it is happening? What is the compaction type? It can be "compaction", but can also be something else, such as

compaction trigger after every fix interval

Hi team, I have a query, in our prod environment, there are multiple key spaces and tables. According to requirements, every table has different compaction strategies like level/time/size. Somehow, when I checked the compaction history, I noticed that compaction occurs every 6 hr for every table.

Re: compaction trigger after every fix interval

Hi Prerna Compactions are triggered automatically based on the compaction strategy. Since you are seeing compactions triggered every 6 hours, the thing that can be happening is you have such a kind of traffic where you have lots of writes every 6 hours. PS: Please use the user mailing list

Apache Cassandra Contributor Call - Next Tuesday April 30th

Hi Everyone! The Apache Cassandra Contributor Call will take place next *Tuesday, April 30th at 10AM PDT / 1PM EDT / 19:00 CET*. This session will feature *Shailaja Koppu* who will be discussing *CEP-33 | CIDR Filtering Authorizer*. You can register for the event on the Planet Cassandra Global

Quick poll on content

Hi everyone, Yesterday, I did a live stream on "GenAI for Cassandra Teams" you can see it on YouTube[1]. I love creating content that helps you work through problems or new things. The GenAI thing has been hitting Cassandra teams with requests for new app features and there are a lot of topics I

Re: Trouble with using group commitlog_sync

Okay, that proves I was wrong on the client side bottleneck. On 24/04/2024 17:55, Nathan Marz wrote: I tried running two client processes in parallel and the numbers were unchanged. The max throughput is still a single client doing 10 in-flight BatchStatement containing 100 inserts. On Tue,

Re: Trouble with using group commitlog_sync

I tried running two client processes in parallel and the numbers were unchanged. The max throughput is still a single client doing 10 in-flight BatchStatement containing 100 inserts. On Tue, Apr 23, 2024 at 10:24 PM Bowen Song via user < user@cassandra.apache.org> wrote: > You might have run

Re: Mixed Cluster 4.0 and 4.1

Hi Paul, IMO, if they are truly risk-adverse, they should follow the tested and proven best practices, instead of doing things in a less tested way which is also know to pose a danger to the data correctness. If they must do this over a long period of time, then they may need to temporarily

Re: Mixed Cluster 4.0 and 4.1

Hi Bowen, Thanks for your quick reply. Sorry I used the wrong term there, there it is a maintenance window rather than an outage. This is a key system and the vital nature of it means that the customer is rightly very risk adverse, so we will only even get permission to upgrade one DC per

Re: Mixed Cluster 4.0 and 4.1

Hi Paul, You don't need to plan for or introduce an outage for a rolling upgrade, which is the preferred route. It isn't advisable to take down an entire DC to do upgrade. You should aim to complete upgrading the entire cluster and finish a full repair within the shortest gc_grace_seconds

Mixed Cluster 4.0 and 4.1

Hi all, We have some large clusters ( 1000+ nodes ), these are across multiple datacenters. When we perform upgrades we would normally upgrade a DC at a time during a planned outage for one DC. This means that a cluster might be in a mixed mode with multiple versions for a week or 2. We

Re: Trouble with using group commitlog_sync

You might have run into the bottleneck of the driver's IO thread. Try increase the driver's connections-per-server limit to 2 or 3 if you've only got 1 server in the cluster. Or alternatively, run two client processes in parallel. On 24/04/2024 07:19, Nathan Marz wrote: Tried it again with

Re: Trouble with using group commitlog_sync

Tried it again with one more client thread, and that had no effect on performance. This is unsurprising as there's only 2 CPU on this node and they were already at 100%. These were good ideas, but I'm still unable to even match the performance of batch commit mode with group commit mode. On Tue,

Re: Trouble with using group commitlog_sync

To achieve 10k loop iterations per second, each iteration must take 0.1 milliseconds or less. Considering that each iteration needs to lock and unlock the semaphore (two syscalls) and make network requests (more syscalls), that's a lots of context switches. It may a bit too much to ask for a

Re: Trouble with using group commitlog_sync

It's using the async API, so why would it need multiple threads? Using the exact same approach I'm able to get 38k / second with periodic commitlog_sync. For what it's worth, I do see 100% CPU utilization in every single one of these tests. On Tue, Apr 23, 2024 at 11:01 AM Bowen Song via user <

Re: Trouble with using group commitlog_sync

Have you checked the thread CPU utilisation of the client side? You likely will need more than one thread to do insertion in a loop to achieve tens of thousands of inserts per second. On 23/04/2024 21:55, Nathan Marz wrote: Thanks for the explanation. I tried again with 

Re: Trouble with using group commitlog_sync

Thanks for the explanation. I tried again with commitlog_sync_group_window at 2ms, concurrent_writes at 512, and doing 1000 individual inserts at a time with the same loop + semaphore approach. This only nets 9k / second. I got much higher throughput for the other modes with BatchStatement of

Re: Trouble with using group commitlog_sync

I suspect you are abusing batch statements. Batch statements should only be used where atomicity or isolation is needed. Using batch statements won't make inserting multiple partitions faster. In fact, it often will make that slower. Also, the liner relationship between

Re: Trouble with using group commitlog_sync

Thanks. I raised concurrent_writes to 128 and set commitlog_sync_group_window to 20ms. This causes a single execute of a BatchStatement containing 100 inserts to succeed. However, the throughput I'm seeing is atrocious. With these settings, I'm executing 10 BatchStatement concurrently at a time

Re: Trouble with using group commitlog_sync

The default commitlog_sync_group_window is very long for SSDs. Try reduce it if you are using SSD-backed storage for the commit log. 10-15 ms is a good starting point. You may also want to increase the value of concurrent_writes, consider at least double or quadruple it from the default.

Re: Trouble with using group commitlog_sync

"batch" mode works fine. I'm having trouble with "group" mode. The only config for that is "commitlog_sync_group_window", and I have that set to the default 1000ms. On Tue, Apr 23, 2024 at 8:15 AM Bowen Song via user < user@cassandra.apache.org> wrote: > Why would you want to set

Re: Trouble with using group commitlog_sync

Why would you want to set commitlog_sync_batch_window to 1 second long when commitlog_sync is set to batch mode? The documentation on this says: /This window should be kept short because the writer threads

Trouble with using group commitlog_sync

I'm doing some benchmarking of Cassandra on a single m6gd.large instance. It works fine with periodic or batch commitlog_sync options, but I'm having tons of issues when I change it to "group". I have "commitlog_sync_group_window" set to 1000ms. My client is doing writes like this (pseudocode):

RE: Datacenter decommissioning on Cassandra 4.1.4

Hello Alain, Thanks a lot for the confirmation. Yes this procedure seems like a workaround. But for my use case where system_auth contains a small amount of data and consistency level for authentication/authorization is switched to LOCAL_ONE, I think it is good enough. I completely get that

RE: Datacenter decommissioning on Cassandra 4.1.4

Hello Sebastien, Yes, your approach is really interesting. I will test this in my system as well. I think it reduces some risks involved in the procedure that was discussed in the previous emails. Just for the record, availability is a top priority for my use cases that is why I have switched the

Re: Datacenter decommissioning on Cassandra 4.1.4

Recently, I successfully used the following procedure when decommissioning a datacenter: 1. Reduced the replication factor for this DC to zero for all keyspaces except the system_auth keyspace. For that keyspace, I reduced the RF to one. 2. Decommissioned all nodes except one in the DC using

Re: Datacenter decommissioning on Cassandra 4.1.4

Hi Michalis, It's been a while since I removed a DC for the last time, but I see there is now a protection to avoid accidentally leaving a DC without auth capability. This was introduced in C* 4.1 through CASSANDRA-17478 ( https://issues.apache.org/jira/browse/CASSANDRA-17478). The process of

Re: ssl certificate hot reloading test - cassandra 4.1

I think in the context of what I think initially motivated this hot reloading capability, a big win it provides is avoiding having to bounce your cluster as your certificates near expiry. If not watched closely you can get yourself into a state where every node in the cluster's cert expired,

Re: ssl certificate hot reloading test - cassandra 4.1

I think it's all part of the same issue and you're not derailing IMO Abe. For the user Pabbireddy here, the unexpected behavior was not closing internode connections on that keystore refresh. So ISTM, from a "featureset that would be nice to have here" perspective, we could theoretically

Re: ssl certificate hot reloading test - cassandra 4.1

Not to derail from the original conversation too far, but wanted to agree that maximum connection establishment time on native transport would be useful. That would provide a maximum duration before an updated client keystore is used for connections, which can be used to safely roll out client

Re: ssl certificate hot reloading test - cassandra 4.1

It seems like if folks really want the life of a connection to be finite (either client/server or server/server), adding in an option to quietly drain and recycle a connection on some period isn’t that difficult. That type of requirement shows up in a number of environments, usually on

Re: ssl certificate hot reloading test - cassandra 4.1

In addition to what Andy mentioned, I want to point out that for the vast majority of use-cases, we would like to _avoid_ interruptions when a certificate is updated so it is by design. If you're dealing with a situation where you want to ensure that the connections are cycled, you can follow

Re: ssl certificate hot reloading test - cassandra 4.1

I should mention, when toggling disablebinary/enablebinary between instances, you will probably want to give some time between doing this so connections can reestablish, and you will want to verify that the connections can actually reestablish. You also need to be mindful of this being disruptive

Re: ssl certificate hot reloading test - cassandra 4.1

Thanks Andy for your reply . We will test the scenario you mentioned. Regards Avinash On Mon, Apr 15, 2024 at 11:28 AM, Tolbert, Andy wrote: > Hi Avinash, > > As far as I understand it, if the underlying keystore/trustore(s) > Cassandra is configured for is updated, this *will not* provoke >

Re: ssl certificate hot reloading test - cassandra 4.1

Hi Avinash, As far as I understand it, if the underlying keystore/trustore(s) Cassandra is configured for is updated, this *will not* provoke Cassandra to interrupt existing connections, it's just that the new stores will be used for future TLS initialization. Via:

ssl certificate hot reloading test - cassandra 4.1

Dear Community, I hope this email finds you well. I am currently testing SSL certificate hot reloading on a Cassandra cluster running version 4.1 and encountered a situation that requires your expertise. Here's a summary of the process and issue: 1. Reloading Process: We reloaded

Trie Memtables

Hey all, Tomorrow at 10:30am PDT I'm taking a look at Trie Memtables tomorrow on my live stream. I'll do some performance comparisons between it and the legacy SkipListMemtable implementation and see what I can learn. https://www.youtube.com/live/Jp5R_-uXORQ?si=NnIoV3jqjHFoD8nF or if you

RE: Datacenter decommissioning on Cassandra 4.1.4

Hello Jon and Jeff, Thanks a lot for your replies. I completely get your points. Some more clarification about my issue. When trying to update the Replication before the decommission, I get the following error message when I remove the replication for system_auth kesypace. ConfigurationException:

Re: Datacenter decommissioning on Cassandra 4.1.4

To Jon’s point, if you remove from replication after step 1 or step 2 (probably step 2 if your goal is to be strictly correct), the nodetool decommission phase becomes almost a no-op. If you use the order below, the last nodes to decommission will cause those surviving machines to run out of

Re: Datacenter decommissioning on Cassandra 4.1.4

You shouldn’t decom an entire DC before removing it from replication. — Jon Haddad Rustyrazorblade Consulting rustyrazorblade.com On Mon, Apr 8, 2024 at 6:26 AM Michalis Kotsiouros (EXT) via user < user@cassandra.apache.org> wrote: > Hello community, > > In our deployments, we usually rebuild

Datacenter decommissioning on Cassandra 4.1.4

Hello community, In our deployments, we usually rebuild the Cassandra datacenters for maintenance or recovery operations. The procedure used since the days of Cassandra 3.x was the one documented in datastax documentation. Decommissioning a datacenter | Apache Cassandra 3.x

Re: Update: C/C NA Call for Presentations Deadline Extended to April 15th

Hi, I would like to send a friendly reminder that the Community Over Code North America 2024 call for presentations ends in a little less than 9 days on Mon, 15 April 2024 22:59:59 UTC. Don't leave your Cassandra submissions to the last minute! :-) Thanks, Paulo On Tue, Mar 19, 2024 at 7:19 PM

Re: Query on Performance Dip

Try changing the chunk length parameter on the compression settings to 4kb, and reduce read ahead to 16kb if you’re using EBS or 4KB if you’re using decent local ssd or nvme. Counters read before write. — Jon Haddad Rustyrazorblade Consulting rustyrazorblade.com On Fri, Apr 5, 2024 at 9:27 AM

Re: Query on Performance Dip

follow up question on performance issue with 'counter writes'- is there a parameter or condition that limits the allocation rate for 'CounterMutationStage'? I see 13-18mb/s for 4.1.4 Vs 20-25mb/s for 4.0.5. The back-end infra is same for both the clusters and same test cases/data model. On

Participate in the ASF 25th Anniversary Campaign

Hi everyone, As part of The ASF’s 25th anniversary campaign[1], we will be celebrating projects and communities in multiple ways. We invite all projects and contributors to participate in the following ways: * Individuals - submit your first contribution:

Re: Query on Performance Dip

Hi, Unfortunately, the numbers you're posting have no meaning without context. The speculative retries could be the cause of a problem, or you could simply be executing enough queries and you have a fairly high variance in latency which triggers them often. It's unclear how many queries / second

Re: Query on Performance Dip

Hi All, On debugging the cluster for performance dip seen while using 4.1.4, i found high speculation retries Value in nodetool tablestats during read operation. I ran the below tablestats command and checked its output after every few secs and noticed that retries are on rising side. Also

Re: Query on Performance Dip

we are seeing similar perf issues with counter writes - to reproduce: cassandra-stress counter_write n=10 no-warmup cl=LOCAL_QUORUM -rate threads=50 -mode native cql3 user= password= -name op rate: 39,260 ops (4.1) and 63,689 ops (4.0) latency 99th percentile: 7.7ms (4.1) and 1.8ms

Re: Cassandra 5.0 Beta1 - vector searching results

> For your #1 - if there are going to be 100+ million vectors, wouldn't I want the search to go across nodes? If you have a replication factor of 3 and 3 nodes, every node will have a complete copy of the data, so you'd only need to talk to one node. If your replication factor is 1, you'd have to

Re: Cassandra 5.0 Beta1 - vector searching results

Thank you all for the details on this. For your #1 - if there are going to be 100+ million vectors, wouldn't I want the search to go across nodes? Right now, we're running both weaviate (8 node cluster), our main cassandra 4 cluster (12 nodes), and a test 3 node cassandra 5 cluster. 

Community Over Code NA 2024 Travel Assistance Applications now open!

Hello to all users, contributors and Committers! [ You are receiving this email as a subscriber to one or more ASF project dev or user mailing lists and is not being sent to you directly. It is important that we reach all of our users and contributors/committers so that they may get a chance

Query on Performance Dip

Hi All, Was going through this mail chain (https://www.mail-archive.com/user@cassandra.apache.org/msg63564.html) and was wondering that if this could cause a performance degradation in 4.1 without changing compactionThroughput. As seeing performance dip in Read/Write after upgrading from 4.0 to

Re: Cassandra 5.0 Beta1 - vector searching results

Hi all, curious if there is support for the new Cassandra vector data type in any open-source Kafka Connect Cassandra Sink connectors please? i.e. To write vector data to Cassandra from Kafka. Regards, Paul From: Caleb Rackliffe Date: Friday, 22 March 2024 at 1:52 pm To:

Apache Cassandra Virtual Meetups this week

Hello Cassandra community! There are two virtual events happening this week. Hope to see you all there. *Cassandra Contributor Call* *CEP-34: mTLS Based Client and Internode Authenticators* Presented by Jyothsna Konica & Dinesh Josh Tuesday, March 26 at 10:00AM PDT

Re: Cassandra 5.0 Beta1 - vector searching results

To expand on Jonathan’s response, the best way to get SAI to perform on the read side is to use it as a tool for large-partition search. In other words, if you can model your data such that your queries will be restricted to a single partition, two things will happen…1.) With all queries (not just

Re: Cassandra 5.0 Beta1 - vector searching results

Hi Joe, Have you considered submitting something for Community Over Code NA 2024? The CFP is still open for a few more weeks, options could be my Performance Engineering track or the Cassandra track – or both 

Re: Cassandra 5.0 Beta1 - vector searching results

Hi Joe, Thanks for testing out vector search! Cassandra 5.0 is about six months behind on vector search progress. Part of this is keeping up with JVector releases but more of it is core improvements to SAI. Unfortunately there's no easy fix for the impedance mismatch between a field where the

Cassandra 5.0 Beta1 - vector searching results

Hi All - I'd like to share some initial results for the vector search on Cassandra 5.0 beta1.  3 node cluster running in kubernetes; fast Netapp storage. Have a table (doc.embeddings_googleflan5tlarge) with definition: CREATE TABLE doc.embeddings_googleflant5large (     uuid text,     type

Re: Alternate apt repo for Debian installation?

Oh, nevermind. It looks like debian.cassandra.apache.org has come back online and I can get once again pull from the apt repo. On Wed, Mar 20, 2024 at 2:15 PM Grant Talarico wrote: > I already tried those. My particular application requires a minimum > version of 3.11.14 and I have 3.11.16

Re: Alternate apt repo for Debian installation?

I already tried those. My particular application requires a minimum version of 3.11.14 and I have 3.11.16 installed in my staging environment. The archive.apache.org only has it's latest of 3.11.13. On Wed, Mar 20, 2024 at 1:55 PM Bowen Song via user < user@cassandra.apache.org> wrote: > You can

Re: Alternate apt repo for Debian installation?

You can try https://archive.apache.org/dist/cassandra/debian/ The deb files can be found here: https://archive.apache.org/dist/cassandra/debian/pool/main/c/cassandra/ On 20/03/2024 20:47, Grant Talarico wrote: Hi there. Hopefully this is the right place to ask this question. I'm trying to

Alternate apt repo for Debian installation?

Hi there. Hopefully this is the right place to ask this question. I'm trying to install the latest version of Cassandra 3.11 using debian packages through the debian.cassandra.apache.org apt repo but it appears to be down at the moment. Is there an alternate apt repo I might be able to use as a

Tomorrow 10AM PDT - Examining LWT perf in 5.0

Hey folks, I'm doing a working session tomorrow at 10am PDT, testing LWTs in C* 5.0. I'll be running benchmarks and doing some performance analysis. Come hang out and bring your questions! Jon YouTube: https://www.youtube.com/watch?v=IoWh647LRQ0 LinkedIn:

Update: C/C NA Call for Presentations Deadline Extended to April 15th

Hi, I wanted to update that the Call for Presentations deadline was extended by two weeks to April 15th, 2024 for Community Over Code North America 2024. Find more information on this blog post:

Re: [EXTERNAL] Re: About Cassandra stable version having Java 17 support

Short answer: There's no definite answer to that question. Longer answer: I doubt such date has already been decided. It's largely driven by the time required to fix known issues and any potential new issues discovered during the BETA and RC process. If you want to track the progress, feel

Re: [EXTERNAL] Re: About Cassandra stable version having Java 17 support

Thanks for your reply. As Cassandra has moved to Java 17 in it's 5.0-BETA1 (Latest release on 2023-12-05). Can you please let us know when the team is planning to GA Cassandra 5.0 version which has Java 17 support? Regards, Divyanshi From: Bowen Song via user

Re: About Cassandra stable version having Java 17 support

Why Java 17? It makes no sense to choose an officially non-supported library version for a piece of software. That decision making process is the problem, not the software's library version compatibility. On 18/03/2024 09:44, Divyanshi Kaushik via user wrote: Hi All, As per my project

Two weeks remaining to submit abstracts to Community Over Code 2024

Hi, I'd like to send a friendly reminder that the deadline for submissions to Community Over Code North America 2024 ends in two weeks on April 1st, 2024. This conference will be held in Denver, Colorado, October 7-10, 2024. We're looking for abstracts in the following areas: * Customizing and

Re: Documentation about TTL and tombstones

> It's actually correct to do it how it is today. > Insertion date does not matter, what matters is the time after tombstones are > supposed to be deleted. > If the delete got to all nodes, sure, no problem, but if any of the nodes > didn't get the delete, and you would get rid of the

About Cassandra stable version having Java 17 support

Hi All, As per my project requirement, Java 17 needs to be used. Can you please let us know when you are planning to release the next stable version of Cassandra having Java 17 support? Regards, Divyanshi This email and any files transmitted with it are confidential, proprietary and intended

Re: Documentation about TTL and tombstones

It's actually correct to do it how it is today. Insertion date does not matter, what matters is the time after tombstones are supposed to be deleted. If the delete got to all nodes, sure, no problem, but if any of the nodes didn't get the delete, and you would get rid of the tombstones before

Re: Documentation about TTL and tombstones

> That's not how gc_grace_seconds work. > gc_grace_seconds controls how much time *after* a tombstone can be deleted, > it can actually be deleted, in order to give you enough time to run repairs. > > Say you have data that is about to expire on March 16 8am, and > gc_grace_seconds is 10 days.

Re: Documentation about TTL and tombstones

That's not how gc_grace_seconds work. gc_grace_seconds controls how much time *after* a tombstone can be deleted, it can actually be deleted, in order to give you enough time to run repairs. Say you have data that is about to expire on March 16 8am, and gc_grace_seconds is 10 days. After Mar 16

Re: Documentation about TTL and tombstones

> by reading the documentation about TTL > https://cassandra.apache.org/doc/4.1/cassandra/operating/compaction/index.html#ttl > It mention that it creates a tombstone when data expired, how does it > possible without writing to the tombstone on the table ? I thought TTL > doesn't create

Documentation about TTL and tombstones

Hello community, by reading the documentation about TTL https://cassandra.apache.org/doc/4.1/cassandra/operating/compaction/index.html#ttl It mention that it creates a tombstone when data expired, how does it possible without writing to the tombstone on the table ? I thought TTL doesn't create

RE: SStables stored in directory with different table ID than the one found in system_schema.tables

Hello everyone, The recovery was performed successfully some days ago. Finally, the problematic datacenter was removed and added back to the cluster. BR MK From: Michalis Kotsiouros (EXT) via user Sent: February 12, 2024 17:59 To: Sebastian Marsching ; user@cassandra.apache.org Cc:

Re: Question about commit consistency level for Lightweight Transactions in Paxos v2

So for upgrading Paxos to v2, the non-serial consistency level should be set to ANY or LOCAL_QUORUM, and the serial consistency level should still be SERIAL or LOCAL_SERIAL. Got it, thanks! From: Laxmikant Upadhyay Date: Tuesday, 12 March 2024 at 7:33 am To: user@cassandra.apache.org Cc:

Call for Presentations: Cassandra @ Community Over Code North America 2024

Hi, After a successful experience in ApacheCon 2022, the Cassandra track is back to Community Over Code North America 2024 to be held in Denver, Colorado, October 7-10, 2024. I will be facilitating this track and I would like to request abstract drafts in the following topics to be presented in

Re: Question about commit consistency level for Lightweight Transactions in Paxos v2

You need to set both in case of lwt. your regular non -serial consistency level will only applied during commit phase of lwt. On Wed, 6 Mar, 2024, 03:30 Weng, Justin via user, wrote: > Hi Cassandra Community, > > > > I’ve been investigating Cassandra Paxos v2 (as implemented in CEP-14 >

Question about commit consistency level for Lightweight Transactions in Paxos v2

Hi Cassandra Community, I’ve been investigating Cassandra Paxos v2 (as implemented in CEP-14) which improves the performance of lightweight transaction (LWT). But I’ve got a question about setting the commit

Streaming a working session with 5.0 - UCS

Hey everyone, Today starting at 10am PT I'm going to be streaming my session messing with 5.0, looking at UCS. I'm doing this with my easy-cass-lab and easy-cass-stress tools using a build of C* from last night. I'll also show some of the cool things you can do with my tools. I'll be running

Re: Best Practices for Managing Concurrent Client Connections in Cassandra

We've used these settings in production with no issues. What has been more valuable to us though is limiting the rate of client connections via iptables. Often times users configure an aggressive reconnection policy that floods the cluster with connections in certain circumstances like a node

Re: Best Practices for Managing Concurrent Client Connections in Cassandra

They are suitable for production use for protecting your Cassandra server, not the clients. The clients likely will experience an error when the limit is reached, and it needs to handle that error appropriately. What you really want to do probably are: 1. change the client's behaviour, limit

Best Practices for Managing Concurrent Client Connections in Cassandra

Hello Cassandra Community, We've been experiencing occasional spikes in the number of client connections to our Cassandra cluster, particularly during high-volume API request periods. We're using persistent connections, and we've noticed that the number of connections can increase significantly

RE: Check out new features in K8ssandra and Mission Control

The k8ssandra requirement is a major blocker. Sean R. Durity INTERNAL USE From: Christopher Bradford Sent: Tuesday, February 27, 2024 9:49 PM To: user@cassandra.apache.org Cc: Christopher Bradford Subject: [EXTERNAL] Re: Check out new features in K8ssandra and Mission Control Hey Jon, *

Re: stress testing & lab provisioning tools

Hey Jon, It's awesome to see that you're reviving both these projects! I was eager to get my hands on an updated version of tlp-cluster with up to date AMIs  tlp-stress is by far the best Cassandra stress tool I've worked with, and I recommend everyone to test easy-cass-stress and build

Re: Check out new features in K8ssandra and Mission Control

Hey Jon, * What aspects of Mission Control are dependent on using K8ssandra? > Mission Control bundles in K8ssandra for the core automation workflows (lifecycle management, cluster operations, medusa &. reaper). In fact we include the K8ssandraSpec in the top-level MissionControlCluster resource

Re: Check out new features in K8ssandra and Mission Control

Hey Chris - this looks pretty interesting! It looks like there's a lot of functionality in here. * What aspects of Mission Control are dependent on using K8ssandra? * Can Mission Control work without K8ssandra? * Is mission control open source? * I'm not familiar with Vector - does it require an

Check out new features in K8ssandra and Mission Control

Hey C* folks, I'm excited to share that the DataStax team has just released Mission Control , a new operations platform for running Apache Cassandra and DataStax Enterprise. Built around the open source core of K8ssandra we've

stress testing & lab provisioning tools

Hey everyone, Over the last several months I've put a lot of work into 2 projects I started back at The Last Pickle, for stress testing Cassandra and for building labs in AWS. You may know them as tlp-stress and tlp-cluster. Since I haven't worked at TLP in almost half a decade, and am the

Re: Question Regarding Cassandra-19336

It looks a crtirical bug for setup with multi DC using high number of vnodes and running full repair with -PR option, since number of parallel repair sessions can be as high as number of vnodes. Thus it can fill up memory causing pom or direct buffer memory oom. It should get prioritized for

Apache Cassandra Contributor Meeting Next Tuesday

Hi Cassandra community! Our next Apache Cassandra Contributor Meeting will feature *Jaydeepkumar Chovatia* and his work on “*CEP-37: The Cassandra Official Repair Solution* ”. *When*: 10:00 PT / 13:00 ET / 17:00 UTC / 22:30 IST. *Register*:

Re: Cassandra 4.1 compaction thread no longer low priority (cpu nice)

Hi, Thanks for your detailed answers. I understand the reason why using low priority compaction may not be a great idea in the general case (the example with too high CPU for reading). I’ll give a try with the compaction throughput which I total forgot that this option exists. It may fix the

Re: Cassandra 4.1 compaction thread no longer low priority (cpu nice)

Thank you for highlighting this, it looks like I need to refresh my knowledge about IO schedulers :-) Cheers, Dmitry On Thu, 22 Feb 2024 at 22:18, Bowen Song via user wrote: > On the IO scheduler point, cfq WAS the only scheduler supporting IO > priorities (such as ionice) shipped by default

Re: Cassandra 4.1 compaction thread no longer low priority (cpu nice)

On the IO scheduler point, cfq WAS the only scheduler supporting IO priorities (such as ionice) shipped by default with the Linux kernel, but that has changed since bfq and mq-deadline were added to the Linux kernel. Both bfq and mq-deadline supports IO priority, as documented here:

Re: Cassandra 4.1 compaction thread no longer low priority (cpu nice)

Hi all, I was not participating in the changes but I analyzed the question some time ago from another side. There were also changes related to -XX:ThreadPriorityPolicy JVM option. When you set a thread priority for a Java thread it does not mean it is always propagated as a native OS thread

Re: Cassandra 4.1 compaction thread no longer low priority (cpu nice)

Hi Pierre, Is there anything stopping you from using the compaction_throughput option in the cassandra.yaml file to manage the performance impact of compaction operations? With

Cassandra 4.1 compaction thread no longer low priority (cpu nice)

Hello all, I've recently upgraded to Cassandra 4.1 and see a change in compaction behavior that seems unwanted: * With Cassandra 3.11 compaction was run by thread in low priority and thus using CPU nice (visible using top) (I believe Cassandra 4.0 also had this behavior) * With Cassandra

Re: Question Regarding Cassandra-19336

The “Since Version” for the ticket is set to 3.0.19, presumably based on C-14096 as the predecessor for this ticket. C-14096 was merged up into 3.11.x in the 3.11.5 release, so 3.11.5 would be the equivalent “since version” for that release series. The patch addressing this ticket is included

Question Regarding Cassandra-19336

Hi All, https://issues.apache.org/jira/browse/CASSANDRA-19336 Does the same issue mentioned in the above JIRA exists for version 3.11.x Regards Ranju

  1   2   3   4   5   6   7   8   9   10   >