[
https://issues.apache.org/jira/browse/CASSANDRA-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anuj updated CASSANDRA-9146:
----------------------------
Attachment: sstables.txt
system-modified.log
Please find attached the logs:
1. system-modified.log = system logs
2. sstables.txt = listing of sstables in ks1cf1 column family in test_ks1
Keyspace
Repair -pr was running on node on 3 instances everytime creating numerous
sstables every second:
2015-04-09 09:14:36 TO 2015-04-09 12:07:28
2015-04-09 14:34 (stopped at 15:07)
2015-04-09 15:11
While only 42 sstables exist for ks1cf1Idx3 as it was compacting
regularly..other two indexes ks1cf1Idx1 and ks1cf1Idx2 have 8932 sstables.
> Ever Growing Secondary Index sstables after every Repair
> --------------------------------------------------------
>
> Key: CASSANDRA-9146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9146
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Anuj
> Attachments: sstables.txt, system-modified.log
>
>
> Cluster has reached a state where every "repair -pr" operation on CF results
> in numerous tiny sstables being flushed to disk. Most sstables are related to
> secondary indexes. Due to thousands of sstables, reads have started timing
> out. Even though compaction begins for one of the secondary index, sstable
> count after repair remains very high (thousands). Every repair adds thousands
> of sstables.
> Problems:
> 1. Why burst of tiny secondary index tables are flushed during repair ? What
> is triggering frequent/premature flush of secondary index sstable (more than
> hundred in every burst)? At max we see one ParNew GC pauses >200ms.
> 2. Why auto-compaction is not compacting all sstables. Is it related to
> coldness issue(CASSANDRA-8885) where compaction doesn't works even when
> cold_reads_to_omit=0 by default?
> If coldness is the issue, we are stuck in infinite loop: reads will
> trigger compaction but reads timeout as sstable count is in thousands
> 3. What's the way out if we face this issue in Prod?
> Is this issue fixed in latest production release 2.0.13? Issue looks similar
> to CASSANDRA-8641, but the issue is fixed in only 2.1.3. I think it should be
> fixed in 2.0 branch too.
> Configuration:
> Compaction Strategy: STCS
> memtable_flush_writers=4
> memtable_flush_queue_size=4
> in_memory_compaction_limit_in_mb=32
> concurrent_compactors=12
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
