运行一个8节点的Cassandra 2.2.5集群，CF大约1TB。
为此CF切换到LeveledCompactionStrategy会导致数千个压缩作业，这本身似乎不是问题。但Cassandra开始使用不断增加的RAM，最终被内核杀死。
C *使用100G RAM合并某些已排序文件的原因可能是什么？
答案 0 :(得分：2)
初始切换到LCS将导致所有数据的大量重新压缩。如果您患有结核病，那就是很多SSTables和许多压实。当Cassandra进行压缩时，它并不像＆＃34;合并一些已排序的文件那么简单＆＃34;因为它实际上必须在SSTables之间合并更新和逻辑删除，需要比简单比较更多的处理。
Compactions将使用RAM，但是除非您配置不同，否则默认值应该对堆大小以及并发压缩数量有限制。虽然说Cassandra会尽可能地利用缓存内存，但这不应该导致问题。
如果你有非常宽的分区，Cassandra在压缩过程中也会使用更多的堆外内存，但是100GB是过多的。我建议你将堆大小，压缩吞吐量和concurrent_compactors配置得更低，以期有望避免使用oom-killer。
如果群集负载不足，您应该使用JMX一次切换到LCS一个节点/机架，请查看本指南以获取信息http://blog.alteroot.org/articles/2015-04-20/change-cassandra-compaction-strategy-on-production-cluster.html
如果群集上没有负载，那么您也可以尝试使用cassandra-env.sh中的disable_stcs_in_l0参数启动cassandra以查看是否有帮助。这将禁用L0中的sizetiered压缩，这应该减少压缩的总数以将所有数据重新压缩为LCS（但是重新压缩仍然需要很长时间才能获得1TB的数据）。
-Dcassandra.disable_stcs_in_l0=true