You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ryan McGuire (JIRA)" <ji...@apache.org> on 2014/02/27 21:58:19 UTC
[jira] [Commented] (CASSANDRA-6746) Reads have a slow ramp up in
speed
[ 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)
Re: [jira] [Commented] (CASSANDRA-6746) Reads have a slow ramp up in speed
Posted by Ryan McGuire <ry...@datastax.com>.
32G nodes. I'm not mucking with heap settings so it's using -Xms8023M
-Xmx8023M -Xmn1600M
Re: [jira] [Commented] (CASSANDRA-6746) Reads have a slow ramp up in speed
Posted by Benedict Elliott Smith <be...@datastax.com>.
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)" <ji...@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)
>