我見過的自舉新節點到Datastax企業卡桑德拉集羣（版本：2.0.10.71）當發生這種情況相當頻繁的問題卡桑德拉：龍新標準桿GC暫停時自舉新節點集羣
當啓動要引導的新節點，引導進程開始從集羣中的其他節點傳輸數據。經過一段時間後（通常爲一分鐘或更短時間） - 羣集中的其他節點顯示高Par新GC暫停時間，然後節點從羣集中退出，使流會話失敗。
INFO [主要] 2015年4月27日16：59：58644 StreamResultFuture.java（線91）[流＃d42dfef0-ecfe-11e4-8099-5be75b0950b8]自流會話與/10.1.214.186
INFO [GossipTasks：1] 2015年4月27日17：01：06342 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：發生07007 StreamSession.java（線454）[流＃d42dfef0-ecfe-11e4-8099-5be75b0950b8]流錯誤
也可參見在日誌中的東西：：02
10.1.219.232 INFO [ScheduledTasks：1] 2015-04-27 18：20：19,987 GCInspector.java（第116行）ParNew的GC：118272 ms for 2 collections，980357368 used;最大爲12801015808
10.1.221.146 INFO [ScheduledTasks：1] 2015-04-27 18：20：29,468 GCInspector.java（line 116）GC for ParNew：154911 ms for 1 collections，1287263224 used;最大是12801015808`
似乎它發生在每次我們嘗試引導新節點時在不同節點上。
我找到了這個相關的票。 https://issues.apache.org/jira/browse/CASSANDRA-6653
我唯一的猜測是，當新的節點出現了很多compactions都發射了，並且可能會導致GC暫停時間，我曾考慮設置concurrent_compactors = 1/2 my total CPU
人有一個想法？
編輯：有關GC設置的更多詳細信息使用i2。上EC2 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
@Tobert我_think_在cassandra.yml上默認被註釋掉 - 這是否意味着它是無限的默認值或設置爲單個壓縮器？ – petecheslock
雖然我現在注意到我們有multithreaded_compaction：false – petecheslock