批量加载后压缩期间的 Cassandra 节点堆压力

Question

在使用 sstableloader 批量加载数据后，每个 Cassandra 节点最终会得到大约 3.000 个大小约为 32MB 的 sstable。

试图减少数量。 sstables 我在每个节点上运行“nodetool compact”。

这种压缩给堆带来了巨大的压力。我尝试使用 8GB 堆（还有 16GB，尽管我知道不建议这样做）。在这两种情况下，C* 节点每次扫描都会进行大约 90 秒的垃圾收集。总之，compaction 无法完成。

每台机器都有 32 GB 的物理内存。批量加载的表使用 STCS 和缓存 = 'keys_only'。

这导致了一些问题：

1. 为什么许多较小的 sstable 在压缩期间对堆的压力比较少、较小的 sstable 更大？
2. 什么是正确的策略来压缩这些批量加载的 sstable？添加堆似乎并不能解决它。
3. 移动一些 sstable 是否安全（使用 linux 命令 mv），使用剩余的 sstable 运行“nodetool compact”。然后 mv 移动的 sstables 回到原来的位置并再次运行“nodetool compact”。 （黑客，我知道）。

更新

实际上，我有这些数量的 sstables - 大多数大小相似。由于内存不足，主要压缩无法完成。而且我找不到一种方法来进行小型压实：

Answer 1

尝试降低concurrent compactors 和threshold for max. in memory row size 的数量。您在使用 SSD 吗？