Cassandra集群突发负载飙升问题求助：40节点集群异常排查咨询

我之前在管理40+节点的Cassandra 3.11.x集群时，刚好碰到过几乎一模一样的问题——单节点CPU突飙、mutation丢包排队，重启后还传染到其他节点。结合自己的排查经验和社区里的同行案例，整理了这些常见原因和排查方向，希望能帮到你：

一、最可能的触发原因 #

• 压缩风暴：Cassandra 3.11.x默认用的SizeTieredCompactionStrategy，要是某个节点攒了一堆SSTable（比如之前有批量写入、TTL清理不及时），达到合并阈值后会突然启动N个压缩任务，直接把CPU和IO占满。重启故障节点后，流量临时转移到其他节点，那些节点积累的SSTable也触发压缩，就出现了“传染”现象。
• 隐性读写热点：你说检查过访问模式，但可能存在藏得深的热点——比如某个业务突发活动导致某一个分区的mutation请求暴增，或者路由逻辑bug把流量全导到了少数节点的副本上。QUORUM一致性下，这些节点要扛三倍的请求压力，CPU直接拉满，处理不过来就会让mutation排队甚至丢失。
• GC停顿“假”CPU飙升：要是JVM堆内存设太大（比如超过8G）、GC参数没调对，长时间Full GC会让GC线程占满CPU，同时节点卡着没法处理请求，mutation队列直接堆起来。重启节点后，其他节点承担了更多流量，GC压力骤增，自然也会出问题。
• 磁盘IO瓶颈引发的CPU等待：如果故障节点的磁盘出问题了（比如坏道、RAID卡缓存失效、存储集群过载），Cassandra的线程会卡在等IO完成，这时top里看iowait占比极高，看起来是CPU飙升，实际是IO拖了后腿。重启后流量转移，其他节点的磁盘也扛不住，就跟着出问题。
• 监控/工具抢资源：要是节点上装的监控代理、日志采集工具（比如配置不合理的Prometheus Agent、Fluentd）太占资源，会直接挤压Cassandra的CPU配额，导致请求处理不及时。
• 版本特定bug：3.11.7有几个已知的坑，比如某些场景下协调器节点处理mutation时的线程泄漏，或者副本同步时的死循环，都会导致CPU持续居高不下。比如CASSANDRA-15857（压缩相关）、CASSANDRA-16265（GC优化）这类官方记录的bug。

二、重点排查的几个方向 #

1. 先从系统层面摸清楚状况 #

• 揪出CPU高的真实原因：用top或htop看是用户态（us）、系统态（sy）还是iowait占比高。iowait高就先查磁盘；us高的话，看看Cassandra的CompactionExecutor、MutationStage这些线程是不是占了大头。
• 检查磁盘IO健康度：跑iostat -x 1看磁盘的util%、await、svctm，要是util接近100%或者await比svctm高很多，那就是磁盘IO瓶颈没跑了。
• 扒GC日志找问题：把Cassandra的GC日志导出来，用GCViewer之类的工具分析，看看是不是有频繁Full GC或者几十秒级的Young GC停顿。重点盯ParNew（CMS）或G1 Young Generation的停顿时间，还有并发阶段的耗时。

2. 深入Cassandra内部看指标 #

• 检查压缩任务状态：跑nodetool compactionstats，看看有没有一堆pending的压缩任务，或者正在运行的任务占用了过多资源。再用nodetool tablestats看各表的SSTable数量，要是远超正常水平，那压缩风暴的概率极大。
• 监控mutation队列：用nodetool tpstats看MutationStage、CommitLogArchiver这些线程池的pending任务数，如果pending一直涨，说明节点处理能力跟不上了。
• 找隐性热点：跑nodetool proxyhistograms看各分区的读写延迟，或者nodetool tablehistograms <keyspace>.<table>，看看有没有某个分区的请求量或延迟异常高。
• 检查副本同步：用nodetool repair -pr看看节点的修复状态，重启后副本同步可能会带来额外负载，要是待同步数据太多，也会压垮CPU。

3. 业务与配置层面再核对一遍 #

• 回溯突变的请求模式：虽然你已经检查过，但可以临时开启Cassandra的查询日志（设置query_logging_enabled: true），看看某个时间段是不是有特定表/分区的mutation请求突增。
• 调整压缩策略：用DESCRIBE TABLE <keyspace>.<table>看表的压缩策略，要是用的SizeTieredCompactionStrategy，写多读少的场景可以考虑换成LeveledCompactionStrategy，或者调小min_threshold、max_threshold参数减少合并次数。
• 优化JVM参数：检查cassandra-env.sh里的MAX_HEAP_SIZE，3.11.x建议堆内存别超过8G（避免GC停顿），同时看看GC参数，比如CMS的CMSInitiatingOccupancyFraction是不是设得太低导致频繁GC。

三、同行碰到过的类似案例 #

社区里不少人都踩过这个坑：

• 某电商集群大促后出现CPU飙升，排查发现是大量过期数据触发的压缩风暴，调整压缩策略和TTL清理规则后解决了问题。
• 一个金融集群因为路由逻辑bug，把所有mutation请求都发到了某个节点的副本上，导致该节点CPU直接拉满，修复路由后就恢复正常了。
• 还有团队遇到过RAID卡缓存失效，导致IO等待过高，看起来是CPU飙升，更换缓存后问题立刻消失。

内容的提问来源于stack exchange，提问作者Stefan Pi