Cassandra节点JVM在节点修复具有物化视图的表时挂起

我在AWS上有一个9节点集群。最近，一些节点出现故障，我想在重新启动后修复集群。但我发现修复操作导致大量memtable刷新，然后JVM GC失败。因此，节点将挂起

我使用的是卡桑德拉3.1.0

java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b32)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b32, mixed mode)

节点硬件为32GB内存和4核CPU。堆是16GB。对于每个节点，大约有200 GB的SST表

JVM挂起速度非常快。维修过程开始后，一切正常。我检查了内存、cpu和IO。没有发现压力。在随机时间之后（流任务正在完成），memtableflushwriter挂起的任务增长非常快，然后GC失败。JVM挂起和heapdump已创建。当问题发生时，CPU的使用率很低，我在AWS EBS磁盘度量中找不到I/O延迟

我检查了堆转储文件。有几个大的memtables对象的表修复。memtable对象的大小约为400-700MB。memtables是在20秒内创建的。此外，我可以看到12000多个memtables。在这些memtables中，有6000个sstable_活动memtables

首先，我怀疑memtable flush编写器是瓶颈。所以我把它增加到4个线程。我将节点的内存加倍。但它不起作用。在修复过程中，挂起的任务快速增加，然后节点再次挂起。我还减少了修复令牌范围，只有一个vnode，但仍然失败

我们可以看到一些这样的日志

WARN [STREAM-IN-/10.0.113.12:7000] 2020-04-02 05:05:57,150 BigTableWriter.java:211 - Writing large partition ....

写sstables有300-500Mbs。一些大的达到2+GB

我浏览了卡桑德拉的源代码。我发现，如果表具有物化视图，则必须在正常的写入过程中处理sstables。所以我怀疑这个问题发生在流媒体的完整阶段

流传输之后，receive回调函数加载更新的分区sstables，并像正常写入一样创建变异。所以它增加了堆中的memtables。此外，它还调用flush（），这将在修复的表之外创建额外的memtables。memtables大小超过清除阈值。所以叫做同花顺。但flush无法释放足够的记忆。有那么多次的同花顺电话。另一方面，刷新也会增加内存表

---

有人遇到同样的问题吗？如果我的结论是正确的，如何修复它？

Cassandra中的Repair不使用memtable-它使用与节点引导等相同的流机制。但是如果您有大分区，并且它们被损坏，那么Cassandra将需要发送它们，而在接收方，它将需要构建辅助结构，等。您可以在中找到有关维修可能出现的问题的更多信息

---

可能的解决方案之一是使用范围修复，因此您只能检查令牌环的特定部分。但手动执行此操作是一项乏味的任务，因此最好使用类似工具的工具来自动化此过程。

谢谢。我已经把代币的范围缩小了。但问题仍然存在。我读了源代码，似乎问题是由物化视图引起的。如果表具有视图，则sstable将通过正常写入路径进行处理。