Anuj created CASSANDRA-8885:
-------------------------------
Summary: Cold sstable count increases indefinitely in STCS
Key: CASSANDRA-8885
URL: https://issues.apache.org/jira/browse/CASSANDRA-8885
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.0.3
Reporter: Anuj
Priority: Minor
This issue is regarding compaction of cold sstables.
Compaction Strategy for CF: Size Tiered (Min Threshold=4 & Max Threshold=8)
Scenario: Run heavy write load (with NO reads) on all 3 nodes of Cassandra
cluster. After some time, compactions stop and sstable count increases
continuously to large numbers (90+) . As writes continue, small sstable of
similar size are added after every few minutes. When writes stop and Cassandra
is idle, compaction doesn't happen automatically and sstable count is still
very high. When we start reads on sstables, compaction is automatically
triggered and sstable count keeps on decreasing to reasonable levels.
We think that behaviour is unexpected because of following reasons:
1. As per documentation
(https://issues.apache.org/jira/browse/CASSANDRA-6109 and
http://www.datastax.com/dev/blog/optimizations-around-cold-sstables),
cold_reads_to_omit is disabled by default in 2.0.3. We are using 2.0.3 and not
enabled cold_reads_to_omit explicitly. Still, cold sstables are not getting
compacted. Coldness should not come in picture by default in 2.0.3.
Note:compactionstats show 0 pending tasks while compaction process is
not happening.
2. In our scenario, we have heavy writes (say for loading data)
followed by reads. Till the time read starts, you have huge no. of sstables to
compact.Significant compactions need to be done before read performance is
restored.
3. Even when Cassandra is kept idle after writes, compaction doesn't
happen. Dont you think compaction should not just look at coldness? It should
also consider load on server and utilize time for compaction when possible.
Cold sstables can be compacted together. This way we will have much less
compactions to do if cold sstables turn hot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
