Cassandra压缩过程内存消耗及ParNew GC过长问题咨询

问题解答 #

a. 压缩过程中需要同时将多少行加载到内存？是仅1行还是多行？ #

Cassandra 执行 minor compaction 时会按分区键排序顺序逐个处理分区，同一个分区在所有参与本次compaction的SSTable中的所有数据片段会被同时加载到内存合并，并非仅加载1行。如果存在超大宽行，Cassandra会按列块拆分处理宽行，避免一次性加载整个宽行，但同一时刻内存中仍会持有来自多个SSTable的同一分区的多个数据片段。

b. 压缩时，每个分区是以decompressed form（解压形式）还是compressed form（压缩形式）读取到内存？ #

若表开启了压缩（默认启用LZ4压缩），compaction 流程读取SSTable时会先读取磁盘上的压缩数据块，解压后以**解压形式（decompressed form）**加载到内存执行合并逻辑，不会以压缩形式在内存中处理。

c. 请问当前场景下，压缩过程是否会占满所有堆内存？ #

不会直接一次性占满全部32GB堆内存，但存在堆内存快速耗尽的高风险：

• 从GC日志可见老年代当前已使用约22GB，占总堆的68%，距离你配置的-XX:CMSInitiatingOccupancyFraction=75的CMS GC触发阈值非常接近
• GC参数中-XX:MaxTenuringThreshold=1的配置意味着对象仅需熬过1次Minor GC就会晋升到老年代，compaction产生的大量临时数据（尤其是解压后最大可达60MB的宽行数据）很容易直接进入老年代，快速抬升老年代使用率，严重时会触发Full GC甚至OOM
• 从GC日志中1.7GB的Eden区大小、-XX:SurvivorRatio=8的配置可推算当前新生代仅约2GB，对于32GB的堆来说占比过低，也是本次ParNew GC停顿超过8秒的核心诱因。

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