我已经看到在将新节点引导到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 ERROR [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行）GC为ParNew：118272 ms为2个集合，980357368使用;最大值是12801015808
10.1.221.146 INFO [ScheduledTasks：1] 2015-04-27 18：20：29,468 GCInspector.java（第116行）用于ParNew的GC：154911 ms用于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”
答案 0 :(得分：4)
在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秒的Gc次）。 FWIW我们在正常操作期间没有看到任何ParNew GC时间 - 只有bootstrap。