Cassandra节点内存溢出(OOM)的预防措施与调试方法咨询

• 堆内存配置核查：确认cassandra-env.sh中Xmx/Xms配置是否符合官方规范，最大堆内存不超过31G，且物理机内存预留至少50%给系统页缓存，禁止将物理内存全部分配给JVM堆。
• 缓存配置核查：确认key_cache_size、row_cache_size配置是否合理，非必要场景不要开启行缓存，避免缓存占用过多堆内存空间。
• 堆外内存使用核查：检查memtable_allocation_type配置，若使用off-heap memtable，需核对max_offheap_memory_size上限是否合理，避免堆外内存占用超过物理机剩余内存阈值。
• 数据模型合理性核查：确认是否存在宽行、超大分区（单分区超过100MB）、未绑定分区范围的全表扫描业务，这类场景会导致单次查询加载大量数据到内存。
• 读写请求参数核查：检查客户端单次查询的分页参数是否合理，是否存在fetch_size设置过大、未开启分页的批量读请求；核实批量写的批次大小是否超过50KB，是否存在跨分区的大批次写入请求。
• 集群任务调度核查：确认是否存在频繁触发的全量repair、节点扩容/数据迁移、快照、压缩策略配置不合理的情况，比如未分级的STCS压缩在大量数据写入时会占用大量内存，同时需核对concurrent_compactors配置是否过高。
• JVM参数配置核查：确认是否开启了不必要的调试参数，是否存在GC策略配置不合理的情况，Cassandra 3.11+推荐使用G1GC，老版本使用CMS GC时需核对新生代、老年代比例配置是否适配业务读写模型。
• 客户端连接核查：核对节点上的客户端连接数是否超过阈值，是否存在连接泄漏，大量空闲连接占用内存资源。

• 第一时间保留现场：若JVM已配置+HeapDumpOnOutOfMemoryError参数，先备份生成的hprof堆快照文件；若未配置该参数且节点还未完全崩溃，先执行jmap -dump:format=b,file=cassandra_oom.hprof <Cassandra进程ID>导出堆快照。同时导出当时的system.log、debug.log、GC日志，以及节点当时的nodetool info、nodetool tpstats、nodetool memtables、nodetool compactionstats输出结果，再执行节点重启操作恢复业务。
• 初步日志排查：先查看system.log中OOM发生前后的错误日志，定位OOM的类型是堆内存溢出、堆外内存溢出还是元空间溢出；查看GC日志确认OOM前是否存在长时间FGC、GC回收率过低的情况。
• 堆快照分析：使用MAT、JProfiler等工具分析hprof快照，优先排查大对象占用：比如是否存在超大memtable、未释放的读请求缓冲区、大量排队的写入任务对象。
• 业务请求侧排查：核对OOM发生时间点的业务请求量变化，是否有新上线的大查询、大批次写入任务，是否存在业务侧误触发的全表扫描请求。
• 异常任务排查：核实OOM发生时节点是否在执行repair、数据清理、压缩、快照等后台任务，确认是否是后台任务占用内存过高触发OOM。
• 根因验证：定位到可疑触发点后，在测试环境复现场景，验证调整配置/优化数据模型/调整业务请求参数后是否还会触发OOM，确认修复方案有效性。

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