Cassandra集群3节点扩容至4节点无显著性能提升的原因排查

咱们来一步步拆解为啥你的Cassandra集群从3节点扩容到4节点后，吞吐量几乎没怎么提升——核心问题集中在硬件资源不均衡、配置与节点能力不匹配、一致性策略与扩容逻辑脱节这几个关键维度：

一、硬件资源严重不均衡是最大瓶颈 #

先看你给出的4节点硬件规格：

N->物理CPU核心数, Ra->总内存, Rf->空闲内存
Node 1: N=16, Ra=189 GB, Rf=165 GB
Node 2: N=16, Ra=62 GB, Rf=44 GB
Node 3: N=12, Ra=24 GB, Rf=38 GB  # 这里明显异常：空闲内存>总内存，监控数据有误或节点资源严重不足
Node 4: N=16, Ra=189 GB, Rf=24 GB

• Node3的硬件规格和其他节点差距极大：总内存仅24GB（其他节点最低62GB），CPU核心数也少4核，这种"木桶短板"会直接拖垮整个集群的扩容收益——新增的Node4能承接负载，但请求一旦分发到Node3，它的处理能力跟不上，整体吞吐量自然上不去。
• 另外Node3的空闲内存居然超过总内存，说明监控数据存在错误，或者该节点正处于内存swap状态，这会导致Cassandra性能暴跌，必须优先排查修复。

二、复制策略与一致性级别的搭配限制了扩容收益 #

你的Keyspace配置是：

CREATE KEYSPACE cass WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '2'} AND durable_writes = true;

同时测试场景的一致性级别是读=2，写=1：

• 副本数为2时，读一致性级别设为2意味着必须从所有2个副本读取并校验一致才返回，扩容到4节点后，每个数据的副本依然只存2个节点，新增的Node4并不会承担读负载，自然读吞吐量无法提升。
• 写一致性级别为1，虽然负载会分散到更多节点，但Node3的性能瓶颈会抵消掉Node4带来的增益，导致整体写吞吐量提升有限。

三、JVM与Cassandra配置存在适配问题 #

1. JVM GC配置不适合大内存场景 #

你用的是CMS GC：

### CMS Settings
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
...

CMS GC在大内存节点（比如Node1/4的189GB内存）上容易产生长时间的GC停顿，尤其是当memtable使用offheap时，老年代的碎片问题会更严重，间接影响集群的吞吐量稳定性。

2. Cassandra统一配置忽略了节点硬件差异 #

你所有节点用的是相同的核心配置：

commitlog_segment_size_in_mb: 32
concurrent_reads: 64
concurrent_writes: 256
memtable_offheap_space_in_mb: 20480  # 20GB的offheap内存
memtable_flush_writers: 1
concurrent_compactors: 2

• 对于总内存仅24GB的Node3来说，20GB的offheap memtable配置完全不合理，会直接导致内存不足触发swap，性能雪崩。
• memtable_flush_writers:1和concurrent_compactors:2的配置，对于16核的Node1/4来说偏低，无法充分利用CPU资源；但对于12核的Node3来说又可能过载，统一配置并不适配异构硬件集群。

四、客户端配置未跟上集群扩容节奏 #

你的客户端IO线程数仅设置为10：

cass_cluster_set_num_threads_io(ms_cluster,10);

当集群扩容到4节点后，客户端的IO线程数没有相应增加，无法充分驱动新增节点的处理能力，成为了客户端侧的瓶颈。另外core_connections_per_host=1的配置也偏低，无法建立足够的连接来发送请求。

针对性优化建议 #

1. 优先修复硬件不均衡问题：

   • 替换或升级Node3的硬件，确保其内存/CPU规格与其他节点对齐；先排查Node3空闲内存异常的问题，解决swap或监控错误。
   • 若暂时无法升级，可调整复制策略，避免将副本分配到Node3（比如通过NetworkTopologyStrategy的节点权重配置降低Node3的副本分配概率）。

2. 调整复制策略与一致性级别：

   • 将Keyspace的副本数调整为dc1:3，这样扩容到4节点后，每个数据的副本会分布到更多节点，分散读写负载；同时读一致性级别可设为QUORUM（此时3节点quorum为2，4节点quorum为2，不会增加读延迟）。

3. 优化JVM与Cassandra配置：

   • 替换CMS GC为G1GC，更适合大内存场景：

     -XX:+UseG1GC
     -XX:MaxGCPauseMillis=200
     -XX:ParallelGCThreads=8
     -XX:ConcGCThreads=4
     

   • 根据节点硬件差异化配置Cassandra：比如给Node3降低memtable_offheap_space_in_mb到8GB，调整concurrent_compactors为1；给Node1/4将concurrent_compactors调整为8，memtable_flush_writers调整为4。

4. 优化客户端配置：

   • 将客户端IO线程数提升到与客户端CPU核心数一致（比如16核客户端设为16）；调整core_connections_per_host到5-10，max_connections_per_host到20-30，确保能充分利用集群节点的处理能力。

内容的提问来源于stack exchange，提问作者Vishal Sharma