I've been investigating this, but a bit slowly as was looking in the wrong place. I haven't yet confirmed, but I have a strong suspicion of the problem. Could you confirm the total physical memory on the nodes? If 8gb or less, try applying the not yet committed patches in CASSANDRA-6692 (atomic b tree improvements), and setting the memtable_cleanup_threshold to 0.2, if you are looking at this today. I suspect it will fix it, although if so it doesn't quite adequately explain the behaviour exactly. If you let me know the cluster you're using I can test the same environment to make sure I'm testing like for like as well. On 27 Feb 2014 20:58, "Ryan McGuire (JIRA)" <j...@apache.org> wrote:
> > [ > https://issues.apache.org/jira/browse/CASSANDRA-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915038#comment-13915038] > > Ryan McGuire commented on CASSANDRA-6746: > ----------------------------------------- > > I tried re-running this with a 'nodetool flush' on each node after it's > done with the write. It looked the same as above. I'm running a test with a > 5 minute wait between the write and read to see if that causes a change. > > > Reads have a slow ramp up in speed > > ---------------------------------- > > > > Key: CASSANDRA-6746 > > URL: > https://issues.apache.org/jira/browse/CASSANDRA-6746 > > Project: Cassandra > > Issue Type: Bug > > Components: Core > > Reporter: Ryan McGuire > > Assignee: Benedict > > Labels: performance > > Fix For: 2.1 beta2 > > > > Attachments: 2.1_vs_2.0_read.png > > > > > > On a physical four node cluister I am doing a big write and then a big > read. The read takes a long time to ramp up to respectable speeds. > > !2.1_vs_2.0_read.png! > > [See data here| > http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.1_vs_2.0_vs_1.2.retry1.json&metric=interval_op_rate&operation=stress-read&smoothing=1 > ] > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) >