我已经看到在将新节点引导到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现在是DOWN 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现在UP
然后在另一个节点上：
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使用; max为12801015808 10.1.221.146 INFO [ScheduledTasks：1] 2015-04-27 18：20：29,468 GCInspector.java（第116行）GC for ParNew：154911 ms for 1 collections，1287263224 used;最大值是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“
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秒的Gc次） . FWIW我们在正常操作期间没有看到任何ParNew GC时间 - 只有bootstrap .