一、生产环境Cassandra节点的痛点与调优必要性
做过互联网后端开发的人都懂，线上服务出问题的噩梦时刻：突然用户反馈系统卡成狗，查监控发现Cassandra的写入延迟飙到几百毫秒甚至几秒，还时不时有几秒钟的完全停顿——别慌，这大概率是JVM在“搞事情”。Cassandra本身是基于Java写的分布式数据库，它的所有数据读写、节点同步、后台压缩这些核心操作，全靠JVM来跑。JVM要是没调教好，就像给跑车装了个普通家用发动机，再强的底盘也跑不起来。
我之前碰到过一个真实场景：某电商大促前，我们的Cassandra集群突然连续出问题，监控面板上的“GC停顿时间”红得刺眼，写入请求的失败率直接冲到了5%，客服那边投诉电话都被打爆了。查了一圈发现，集群刚扩容完，新节点的JVM配置完全是默认值，老节点的配置也是两年前随便设的，根本没跟着业务数据量的增长调整。从那次之后，我就总结出一套针对生产环境Cassandra的JVM调优思路，核心就是调整堆大小、换合适的GC算法、分析GC日志，这三步解决了90%以上的Cassandra性能问题。
二、堆大小调整：先给Cassandra“分对内存”
Cassandra的JVM内存分两部分：堆内存（Heap）和堆外内存（Off-Heap），这俩是互补的，不能只盯着堆内存调。堆内存主要存Cassandra的元数据、用户读写请求的临时数据、后台压缩任务的中间结果；堆外内存主要存SSTable的缓存、节点间的网络缓冲区这些。
2.1 堆大小的核心原则
很多人容易踩的坑是把堆内存设得太大或者太小：设太小，堆里的垃圾回收会特别频繁，就像垃圾桶满了反复倒；设太大，一次GC停顿的时间会特别长，因为要扫的内存太多了。
行业里对Cassandra堆大小有个公认的黄金范围：4G到8G。这个范围是经过无数次生产环境验证的——既不会让GC太频繁，也不会让单次GC停顿太久。那如果服务器的内存很大，比如一台机器有64G、128G内存，剩下的内存怎么办？全部分给堆外内存就行，Cassandra的堆外内存对大内存的利用率反而比堆内存高。
2.2 堆大小调整的具体操作
调整堆大小其实就是改Cassandra启动时的JVM参数，核心参数是-Xms和-Xmx：-Xms是堆的初始大小，-Xmx是堆的最大大小。生产环境里必须把这俩设成一样大，不然JVM会在运行中动态调整堆大小，反而会带来额外的性能开销。
举个具体的例子，我们之前给一台16G内存的Cassandra节点调参数：
# 打开Cassandra的JVM配置文件，不同版本路径可能略有不同，这里是3.x版本的路径
vim /opt/cassandra/conf/jvm.options
# 注释掉原来的默认配置（一般默认是-Xms4G -Xmx4G）
# -Xms4G
# -Xmx4G
# 改成适合16G节点的配置：堆大小设为6G，剩下的10G左右分给堆外
-Xms6G
-Xmx6G
改完之后要重启Cassandra节点才能生效，不过生产环境里不能直接硬重启，得先做节点降级（把节点上的流量切走），重启完再把流量切回来，避免影响线上业务。
三、GC算法选择：给Cassandra找个“合适的清洁工”
GC算法就是JVM的“内存清洁工”，不同的清洁工干活的方式不一样，有的适合快速倒垃圾，有的适合不打扰正常工作。Cassandra的业务特点是“高并发读写、长时间运行”，所以选GC算法的核心要求是“停顿时间短”，不能一打扫就卡半天。
3.1 常见GC算法的适配性
先给大家科普下常用的GC算法，不用记复杂的原理，只要记清楚适合什么场景就行：
- Serial GC：单线程的清洁工，只适合特别小的内存，生产环境的Cassandra绝对不能用。
- Parallel GC：多线程一起倒垃圾，但是倒的时候会暂停所有正常工作，停顿时间比较长，适合对停顿时间不敏感的场景，比如后台批处理。
- CMS GC：并发清洁工，大部分时间和正常工作一起干，只有小部分时间暂停，停顿时间短，是老版本JDK（JDK7、JDK8）的首选。
- G1 GC：新一代的清洁工，把内存分成很多块，每次只打扫一部分，停顿时间可控，适合大内存的场景，是JDK9及以上版本的首选。
3.2 生产环境的GC算法配置
我们之前的集群用的是JDK8，所以选的是CMS GC，具体配置如下：
# 继续编辑jvm.options文件，注释掉原来的默认GC配置
# -XX:+UseConcMarkSweepGC
# -XX:+CMSParallelRemarkEnabled
# -XX:+CMSClassUnloadingEnabled
# 重新配置CMS的核心参数，确保停顿时间短
-XX:+UseConcMarkSweepGC # 启用CMS GC
-XX:+CMSParallelRemarkEnabled # 启用并行的重新标记阶段，减少停顿时间
-XX:+CMSClassUnloadingEnabled # 允许回收永久代的类，避免永久代溢出
-XX:CMSInitiatingOccupancyFraction=70 # 当堆内存使用率达到70%时，就启动CMS的清理工作
-XX:+UseCMSInitiatingOccupancyOnly # 只按上面的70%阈值启动清理，不用JVM的默认阈值
这里解释下为什么设70%：CMS GC的清理工作需要时间，如果堆内存使用率太高才启动，很可能还没清理完，堆内存就满了，触发“Full GC”，停顿时间会特别长。设成70%，就是给清理工作留够缓冲时间。
如果你的集群用的是JDK11及以上，就可以用G1 GC，配置更简单，核心参数如下：
# JDK11及以上的G1 GC配置
-XX:+UseG1GC # 启用G1 GC
-XX:MaxGCPauseMillis=200 # 要求单次GC的停顿时间不超过200毫秒
-XX:G1HeapRegionSize=16M # 把堆内存分成16M的块，适合6G的堆大小
G1 GC的“MaxGCPauseMillis”参数就是核心，你可以根据业务对停顿时间的要求调整，比如业务要求不能有超过100毫秒的停顿，就设成100。
四、GC日志分析：找到性能问题的“病根”
调完堆大小和GC算法，不能就不管了，得用GC日志来验证效果，找到隐藏的性能问题。GC日志就是JVM每次打扫内存的“工作记录”，里面会记清楚什么时候打扫的、打扫了多久、打扫前后的内存大小这些关键信息。
4.1 开启GC日志
首先得让JVM把GC日志打出来，还是改jvm.options文件，配置如下：
# 配置GC日志的输出路径，生产环境里要确保这个路径的磁盘空间足够
-XX:+PrintGCDetails # 打印详细的GC日志
-XX:+PrintGCDateStamps # 打印GC发生的时间戳，方便和业务监控对应
-XX:+PrintGCTimeStamps # 打印JVM启动后的时间戳，方便分析GC的频率
-XX:+PrintHeapAtGC # 打印GC前后的堆内存使用情况
-XX:+PrintGCApplicationStoppedTime # 打印GC导致的应用停顿时间
-XX:+PrintGCApplicationConcurrentTime # 打印GC期间应用正常运行的时间
-Xloggc:/opt/cassandra/logs/gc.log # 指定GC日志的输出文件
改完重启节点，就会在指定路径下生成gc.log文件。
4.2 分析GC日志的核心指标
拿到GC日志后，不用逐行看，只要盯着几个核心指标就行：
- GC停顿时间：就是日志里的“Total time for which application threads were stopped”，这个时间越短越好，生产环境里最好控制在200毫秒以内。
- GC频率：就是两次GC之间的时间间隔，频率越高，说明堆内存的垃圾越多，要么是堆大小不够，要么是GC算法不合适。
- Full GC的次数：Full GC是最严重的停顿，生产环境里最好一个小时都不要有一次Full GC，如果频繁出现Full GC，说明堆大小设得太小，或者堆外内存不够。
举个例子，我们之前有个节点的GC日志里出现了这样的内容：
2024-05-20T14:30:00.123+0800: 1234.567: [GC (CMS Initial Mark) [1 CMS-initial-mark: 456789K(6144000K)] 456789K(6144000K), 0.002345 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
2024-05-20T14:30:01.456+0800: 1235.890: [GC (CMS Final Remark) [1 CMS-final-mark: 467890K(6144000K)] 467890K(6144000K), 0.012345 secs] [Times: user=0.05 sys=0.00, real=0.01 secs]
2024-05-20T14:30:02.789+0800: 1237.223: [Full GC (CMS Initial Mark) [1 CMS-initial-mark: 567890K(6144000K)] 567890K(6144000K), 1.234567 secs] [Times: user=3.45 sys=0.12, real=1.23 secs]
从这个日志里能看到，出现了一次Full GC，停顿时间是1.23秒，这就是导致写入延迟飙升的原因。后来我们查了发现，这个节点的堆外内存设得太小，导致很多本该存在堆外的数据被挤到了堆里，堆内存的使用率很快就到了阈值，频繁触发GC，最后堆内存不够用，触发了Full GC。我们把堆外内存调大之后，Full GC就消失了，写入延迟也降到了正常水平。
五、调优的应用场景、优缺点与注意事项
5.1 应用场景
这套调优方法适合所有生产环境的Cassandra集群，尤其是以下几种场景：
- 高并发读写的业务场景，比如电商的订单系统、社交平台的消息系统。
- 大内存服务器的集群，比如单节点内存32G、64G的集群。
- 对延迟敏感的业务场景，比如实时推荐、实时风控。
5.2 调优的优缺点
优点：
- 操作简单，只要改几个配置参数，不用改代码，就能解决大部分性能问题。
- 效果明显，调完之后，GC停顿时间和写入延迟能下降50%以上。
- 成本低，不用额外增加硬件成本，就能提升集群的性能。
缺点：
- 调优效果依赖于业务场景和服务器配置，没有万能的参数，需要根据实际情况调整。
- 调优过程需要重启节点，生产环境里需要做降级处理，有一定的操作风险。
- GC日志分析需要一定的经验，新手可能会看不懂日志里的问题。
5.3 注意事项
- 生产环境调优必须做灰度测试，先调一个节点，观察一段时间没问题，再调其他节点，不能一次性调完所有节点。
- 调优前必须备份配置文件，万一调完出问题，能快速回滚。
- 调优后必须持续监控，观察GC停顿时间、写入延迟、节点负载这些指标，确保调优效果。
- 堆大小的调整要和堆外内存的调整配合，不能只调堆内存。
六、调优总结
Cassandra的JVM调优核心就是“分对内存、选对清洁工、找对病根”：先把堆大小设到4G到8G的黄金范围，剩下的内存分给堆外；再根据JDK版本选合适的GC算法，JDK8选CMS，JDK11及以上选G1；最后通过GC日志分析验证调优效果，找到隐藏的性能问题。
这套方法我已经在多个生产环境里验证过，能解决90%以上的Cassandra性能问题，帮很多团队解决了大促前的性能瓶颈。其实JVM调优并不难，只要抓住核心逻辑，不用记复杂的原理，就能把Cassandra的性能发挥到极致。
评论
围绕“生产环境Cassandra节点JVM调优关键参数实战通过调整堆大小GC算法与GC日志分析解决频繁停顿和写入延迟飙升”参与讨论