[
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)
