[ https://issues.apache.org/jira/browse/CASSANDRA-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14047150#comment-14047150 ]
Jackson Chung commented on CASSANDRA-7467: ------------------------------------------ please ignore prev comment. 2 nodes misbehaved over night while repair was running (on another node), and crontab flush is already disabled. > flood of "setting live ratio to maximum of 64" from repair > ---------------------------------------------------------- > > Key: CASSANDRA-7467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7467 > Project: Cassandra > Issue Type: Bug > Reporter: Jackson Chung > > we are on 2.0.8 > running with repair -pr -local <KS>, all nodes on i2.2x (60G ram);, with > setting 8G of heap. Using java 8. (key cache size is 1G) > On occasion, when repair is run, the C* that run the repair, or another node > in the cluster, or both, run into a bad state with the system.log just > printing ""setting live ratio to maximum of 64" forever every split seconds. > It usually happens when repairing one of the larger/wider CF. > WARN [MemoryMeter:1] 2014-06-28 09:13:24,540 Memtable.java (line 470) > setting live ratio to maximum of 64.0 instead of Infinity > INFO [MemoryMeter:1] 2014-06-28 09:13:24,540 Memtable.java (line 481) > CFS(Keyspace='RIQ', ColumnFamily='MemberTimeline') liveRatio is 64.0 > (just-counted was 64.0). calculation took 0ms for 0 cells > Table: MemberTimeline > SSTable count: 13 > Space used (live), bytes: 17644018786 > ... > Compacted partition minimum bytes: 30 > Compacted partition maximum bytes: 464228842 > Compacted partition mean bytes: 54578 > Just to give an idea of how bad this is, the log file is set to rotate 50 > times with 21M each. In less than 15 minutes, all the logs are filled up with > just that log. C* is not responding, and can't be killed normally. Only way > is to kill -9 -- This message was sent by Atlassian JIRA (v6.2#6252)