[ https://issues.apache.org/jira/browse/CASSANDRA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970244#action_12970244 ]
Ryan King commented on CASSANDRA-1083: -------------------------------------- I agree. I think this idea is mostly a dead end because its attacking the problem from the wrong direction. > Improvement to CompactionManger's submitMinorIfNeeded > ----------------------------------------------------- > > Key: CASSANDRA-1083 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1083 > Project: Cassandra > Issue Type: Improvement > Reporter: Ryan King > Assignee: Tyler Hobbs > Priority: Minor > Fix For: 0.7.1 > > Attachments: 1083-configurable-compaction-thresholds.patch, > 1083-sort.txt, compaction_simulation.rb, compaction_simulation.rb > > > We've discovered that we are unable to tune compaction the way we want for > our production cluster. I think the current algorithm doesn't do this as well > as it could, since it doesn't sort the sstables by size before doing the > bucketing, which means the tuning parameters have unpredictable results. > I looked at CASSANDRA-792, but it seems like overkill. Here's an alternative > proposal: > config operations: > minimumCompactionThreshold > maximumCompactionThreshold > targetSSTableCount > The first two would mean what they currently mean: the bounds on how many > sstables to compact in one compaction operation. The 3rd is a target for how > many SSTables you'd like to have. > Pseudo code algorithm for determining whether or not to do a minor compaction: > {noformat} > if sstables.length + minimumCompactionThreshold -1 > targetSSTableCount > sort sstables from smallest to largest > compact the up to maximumCompactionThreshold smallest tables > {noformat} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.