Hi,
In reply to Dikang Gu:
For the run where we incorporated the change from CASSANDRA-11571 the
stack trace was like this (from JMC):
*Stack Trace* *Sample Count* *Percentage(%)*
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(int)
229 11.983
On Sat, Nov 26, 2016 at 6:30 PM, Dikang Gu wrote:
> Hi Marcus,
>
> Do you have some stack trace to show that which function in the `
> getNextBackgroundTask` is most expensive?
>
> Yeah, I think having 15-20K sstables in L0 is very bad, in our heavy-write
> cluster, I try my
> The reason is described here:
https://issues.apache.org/jira/browse/CASSANDRA-5371?focusedCommentId=13621679=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13621679
>
> /Marcus
"...a lot of the work you've done you will redo when you compact your now
bigger L0 sstable
The reason is described here:
https://issues.apache.org/jira/browse/CASSANDRA-5371?focusedCommentId=13621679=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13621679
/Marcus
On Wed, Nov 23, 2016 at 6:31 PM, Jeff Jirsa
wrote:
> What you’re
What you’re describing seems very close to what’s discussed in
https://issues.apache.org/jira/browse/CASSANDRA-10979 - worth reading that
ticket a bit.
There does seem to be a check for STCS in L0 before it tries higher levels:
Without yet reading the code, what you describe sounds like a reasonable
optimization / fix, suitable for 3.0+ (probably not 2.2, definitely not 2.1)
--
Jeff Jirsa
> On Nov 23, 2016, at 7:52 AM, Marcus Olsson wrote:
>
> Hi everyone,
>
> TL;DR
> Should LCS be