Re: STCS in L0 behaviour

2016-12-02 Thread Marcus Olsson
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

Re: STCS in L0 behaviour

2016-11-28 Thread Eric Evans
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

Re: STCS in L0 behaviour

2016-11-24 Thread Nate McCall
> 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

Re: STCS in L0 behaviour

2016-11-24 Thread Marcus Eriksson
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

Re: STCS in L0 behaviour

2016-11-23 Thread Jeff Jirsa
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:

Re: STCS in L0 behaviour

2016-11-23 Thread Jeff Jirsa
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