Cassandra节点因RangeTombstoneList对象引发OOM问题排查

首先，结合你的堆转储信息、查询追踪和cfstats结果来看，OOM的根源大概率还是和Range Tombstones（范围墓碑）有关，只是你的检测方式没覆盖到这类墓碑的统计，再加上Cassandra 2.1版本本身的墓碑处理缺陷，才导致了内存暴涨。下面具体拆解：

1. 为什么cfstats没显示墓碑，但堆里有大量RangeTombstoneList？ #

Cassandra 2.1的cfstats命令统计的tombstones指标，默认只统计行级或单元格级的墓碑，而**Range Tombstones（范围墓碑）**是完全不同的类型，不会被这个指标统计到。

范围墓碑通常由以下操作产生：

• 执行带范围条件的删除，比如 DELETE FROM file_download WHERE ti = 'xxx' AND uuid > 'yyy';
• 批量过期的TTL数据（当大量数据在同一时间窗口过期时，Cassandra可能会生成范围墓碑来优化存储）

这类墓碑会被存储在memtable或sstables中，当查询需要验证数据是否被删除时，就会加载对应的RangeTombstoneList对象到内存——而你的场景是16个并发线程同时加载这类对象，每个占200-240MB，直接就把堆内存撑爆了。

2. 单分区查询为什么会触发RangeTombstoneList加载？ #

虽然你的查询是单分区精准查询，但如果这个分区曾经产生过范围墓碑（比如之前批量删除过该分区内的部分数据），Cassandra在执行查询时，必须加载该分区相关的所有Range Tombstones，来确认返回的结果中没有被删除的数据。在2.1版本中，这个加载逻辑没有做优化，会把整个RangeTombstoneList完整加载到内存，并发场景下内存占用会快速叠加。

3. 具体的排查与解决步骤 #

（1）验证Range Tombstones的存在 #

用Cassandra自带的sstablemetadata工具检查目标表的sstables，确认是否有大量范围墓碑：

# 替换为你的表数据路径和sstable文件名
sstablemetadata /var/lib/cassandra/data/ddp/file_download-<table-uuid>/<sstable-filename>

在输出中查找Range Tombstones相关字段，如果数量较多，就坐实了问题根源。

（2）调整删除/TTL逻辑（队列表的最佳实践） #

你的表被用作队列，这本身就不是Cassandra的理想场景，但可以通过优化读写逻辑减少墓碑：

• 不要用范围删除（DELETE WHERE ...带范围条件），而是按时间分区（比如按天创建分区键），定期删除整个分区（DROP PARTITION），这种操作不会产生范围墓碑；
• 如果用TTL，避免给大量数据设置相同的TTL时间，尽量分散过期时间，减少批量范围墓碑的生成。

（3）优化Compaction策略 #

队列类表适合用TimeWindowCompactionStrategy（TWCS），它会按时间窗口合并sstables，及时清理过期数据和墓碑。注意：Cassandra 2.1的TWCS是实验性特性，建议升级到2.1.20+版本获得更好的稳定性，或者直接升级到3.x版本（长期维护，对TWCS和墓碑处理有大量优化）。

如果暂时不能换策略，可以手动触发一次全量compaction，清理堆积的墓碑：

nodetool compact ddp file_download

（4）缓解内存压力的临时措施 #

• 适当降低concurrent_reads配置（默认是32），减少并发查询的线程数，避免多个线程同时加载RangeTombstoneList；
• 调整JVM堆内存（不要超过8GB，避免GC停顿问题），但这只是治标不治本，核心还是要解决墓碑堆积问题。

（5）长期解决方案：升级Cassandra版本 #

Cassandra 2.1已经停止维护多年，后续的3.x、4.x版本对墓碑处理、内存管理做了大量优化：

• 更高效的Range Tombstone加载逻辑，不会一次性加载完整的列表；
• 更好的GC调优和内存泄漏修复；
• 稳定的TWCS实现，更适合队列类时间序列表。

内容的提问来源于stack exchange，提问作者Bo Finnerup Madsen