cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6746) Reads have a slow ramp up in speed
Date Fri, 14 Mar 2014 18:40:45 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935429#comment-13935429
] 

Jonathan Ellis commented on CASSANDRA-6746:
-------------------------------------------

I think compaction and new flushes are distinct scenarios.

# On compaction, the current default of WONTNEED most data, but WILLNEED partitions that are
hot in the key cache, seems like the Right Thing To Do for datasets that are larger than memory
(i.e., almost all production datasets)
# On flush, we default to WONTNEED, which is probably equivalent to no advice for larger-than-memory
datasets but harms us unnecessarily on smaller datasets

So while I'd be okay with changing the default on flush, I'm not okay with changing it for
compaction.  Right now those are not distinguished by SSTableWriter so it would be a bit more
work.  But, that wouldn't be sufficient to make our test here look good because nothing will
be hot yet when compaction first kicks in.

So at the end of the day, we need CCM to explicitly request non-default behavior either way.

> 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, 6746-patched.png, 6746.txt, cassandra-2.0-bdplab-trial-fincore.tar.bz2,
cassandra-2.1-bdplab-trial-fincore.tar.bz2
>
>
> 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.2#6252)

Mime
View raw message