Re: Cassandra with RHEL 8.6

[Tibor Répási]

That doesn’t sound like a RHEL issue. Swapping can severely impact performance, 
that’s why it is recommended to turn off swap on Cassandra nodes. This was 
recommended in the Cassandra documentation by DataStax[1]. Apache Cassandra is 
testing that and log a warning on startup [2] if swap is found enabled.

Alternatively, the kernel behaviour can be tuned by setting the IO cost of 
swapping [3] that best fit your use-case. For a Cassandra node having 
sufficient physical memory this might end up at zero swappiness to prevent 
swapping at all [4].

[1] 
https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/install/installRecommendSettings.html#Disableswap
 

[2] 
https://github.com/apache/cassandra/blob/738dfde73560d289218f3afa4103a37e9f401757/src/java/org/apache/cassandra/utils/SigarLibrary.java#L172
 

[3] 
https://docs.kernel.org/admin-guide/sysctl/vm.html?highlight=swappiness#swappiness
 

 
[4] 
https://www.ibm.com/docs/en/linux-on-systems?topic=settings-setting-swappiness-parameter-zero
 

 

> On 27. Jul 2023, at 10:14, manish khandelwal  
> wrote:
> 
> Has anybody seen issues running Cassandra on RHEL 8.6. I am seeing 
> performance dip while running Cassandra on RHEL8.6. Also with RHEL I am 
> seeing swapping happening in spite of a lot of free memory available. In RHEL 
> 7.9 we did not see any swapping with same workload and same RPM of Cassandra. 
> Anyone running Cassandra on RHEL? 
> 
> Regards
> Manish

Re: Understanding rack in cassandra-rackdc.properties

[Tibor Répási]

Usually, it’s a good practice to resemble the real datacenter in the Cassandra 
topology, thus nodes mounted to distinct racks are know with different rack 
names to Cassandra. This is due to the usual datacenter infrastructure, having 
a single point of failure in each rack - e.g. a network switch. In that sense a 
rack can be considered a failure domain within the datacenter. Cassandra is 
making efforts to distribute its token ranges among the available nodes to 
minimize intersections within a singe rack. In the best case you can lose a 
whole rack without loosing more than a single replica of the affected 
partitions. (Note: this is just best effort)
In some cases you can experience issues, e.g. if the number of nodes is very 
small, if nodes share some other resources that behave as single point of 
failure - like VMs do, etc. In such a case it might be better to configure each 
Cassandra node with the same rack.

> On 3. Apr 2023, at 17:11, David Tinker  wrote:
> 
> I have a 3 node cluster using the GossipingPropertyFileSnitch and replication 
> factor of 3. All nodes are leased hardware and more or less the same. The 
> cassandra-rackdc.properties files look like this:
> 
> dc=dc1
> rack=rack1
> (rack2 and rack3 for the other nodes)
> 
> Now I need to expand the cluster. I was going to use rack4 for the next node, 
> then rack5 and rack6 because the nodes are physically all on different racks. 
> Elsewhere on this list someone mentioned that I should use rack1, rack2 and 
> rack3 again.
> 
> Why is that?
> 
> Thanks
> David
>