[
https://issues.apache.org/jira/browse/CASSANDRA-10829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064320#comment-15064320
]
Carl Yeksigian commented on CASSANDRA-10829:
--------------------------------------------
We need to ensure we only {{unmarkCompacting}} the sstables which we haven't
already unmarked, otherwise we could be running a different compaction
operation on the previously unmarked sstables and unmark it again after this
operation is finished.
> cleanup + repair generates a lot of logs
> ----------------------------------------
>
> Key: CASSANDRA-10829
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10829
> Project: Cassandra
> Issue Type: Bug
> Environment: 5 nodes on Cassandra 2.1.11 (on Debian)
> Reporter: Fabien Rousseau
> Assignee: Marcus Eriksson
> Fix For: 2.1.x
>
>
> One of our node generates a lot of cassandra logs (int the 10 MB/s) and CPU
> usage has increased (by a factor 2-3).
> This was most probably triggered by a "nodetool snapshot" while a cleanup was
> already running on this node.
> An example of those logs:
> 2015-12-08 09:15:17,794 INFO
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to
> capture released readers [...]
> 2015-12-08 09:15:17,794 INFO
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to
> capture all readers [...]
> 2015-12-08 09:15:17,795 INFO
> [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to
> capture released readers [...]
> 2015-12-08 09:15:17,795 INFO
> [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to
> capture all readers [...]
> (I removed SSTableReader information because it's rather long... I can share
> it privately if needed)
> Note that the date has not been changed (only 1ms between logs)
> It should not generate that gigantic amount of logs :)
> This is probably linked to:
> https://issues.apache.org/jira/browse/CASSANDRA-9637
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
