Cassandra：将新节点引导到集群时，Long Par New GC 暂停

Posted 2023-03-22

【中文标题】Cassandra：将新节点引导到集群时，Long Par New GC 暂停

【英文标题】：Cassandra: Long Par New GC Pauses when Bootstrapping new nodes to cluster

【发布时间】：2015-07-06 11:32:21

【问题描述】：

我发现在将新节点引导到 Datastax Enterprise Cassandra 集群（版本：2.0.10.71）时经常发生的问题

当启动要引导的新节点时，引导进程开始从集群中的其他节点流式传输数据。短时间（通常是一分钟或更短时间）后 - 集群中的其他节点显示较高的 Par New GC 暂停时间，然后节点从集群中退出，导致流会话失败。

INFO [main] 2015-04-27 16:59:58,644 StreamResultFuture.java（第 91 行）[Stream #d42dfef0-ecfe-11e4-8099-5be75b0950b8] 使用 /10.1.214.186 开始流会话

INFO [GossipTasks:1] 2015-04-27 17:01:06,342 Gossiper.java（第 890 行）InetAddress /10.1.214.186 现在已关闭

INFO [HANDSHAKE-/10.1.214.186] 2015-04-27 17:01:21,400 OutboundTcpConnection.java（第 386 行）与 /10.1.214.186 的握手版本

INFO [RequestResponseStage:11] 2015-04-27 17:01:23,439 Gossiper.java（第 876 行）InetAddress /10.1.214.186 现在已启动

然后在另一个节点上：

10.1.214.186 错误 [STREAM-IN-/10.1.212.233] 2015-04-27 17:02:07,007 StreamSession.java（第 454 行）[Stream #d42dfef0-ecfe-11e4-8099-5be75b0950b8] 发生流错误

还可以查看日志中的内容：

10.1.219.232 INFO [ScheduledTasks:1] 2015-04-27 18:20:19,987 GCInspector.java（第 116 行）ParNew 的 GC：2 个集合的 118272 毫秒，使用了 980357368；最大值为 12801015808

10.1.221.146 INFO [ScheduledTasks:1] 2015-04-27 18:20:29,468 GCInspector.java（第 116 行）ParNew 的 GC：154911 毫秒用于 1 个集合，使用了 1287263224；最大值为 12801015808`

似乎每次我们尝试引导一个新节点时它都会发生在不同的节点上。

我找到了这张相关的票证。 https://issues.apache.org/jira/browse/CASSANDRA-6653

我唯一的猜测是，当新节点出现时，会触发大量压缩，这可能会导致 GC 暂停时间，我曾考虑设置 concurrent_compactors = 1/2 my total CPU

有人有想法吗？

编辑：有关 GC 设置的更多详细信息 在 EC2 上使用 i2.2xlarge 节点：

MAX_HEAP_SIZE="12G"

HEAP_NEWSIZE="800M"

还有

JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC"

JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC"

JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled"

JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8"

JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=1"

JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75"

JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly"

JVM_OPTS="$JVM_OPTS -XX:+UseTLAB"

【问题讨论】：

增加并发压缩器通常是个好主意。 core_count/2 是一个很好的起点。

@Tobert 我认为默认值在 cassandra.yml 中被注释掉 - 这是否意味着它是无限制的默认值或设置为单个压缩器？

虽然我现在注意到我们有 multithreaded_compaction: false

关闭多线程。您可以将 tpstats 的输出粘贴到具有原始设置的节点上吗？我很想看看同花顺的作家在做什么。

@PatrickMcFadin - 这是一个 nodetool tpstats 输出 - gist.github.com/petecheslock/dcc72f15799c08d130e5 所有节点都非常相似。 FWIW 在过去的几个月里，我已经替换/重新传输了许多节点。

【参考方案1】：

在 DSE 工作人员的帮助下 - 以下设置帮助了我们。

使用 i2.2xlarge 节点（8 cpu，60G 内存，仅限本地 SSD）

将堆新大小增加到 512M * num CPU（在我们的例子中是 4G） 设置 memtable_flush_writers = 8 设置 concurrent_compactors = 总 CPU / 2（在我们的例子中为 4）

进行这些更改后，ParNew GC 时间在引导程序上不再超过 1 秒（以前我们看到 50-100 SECOND GC 时间）。 FWIW 我们在正常操作期间看不到任何 ParNew GC 时间 - 只有引导程序。