[
https://issues.apache.org/jira/browse/CASSANDRA-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945879#comment-13945879
]
Benedict commented on CASSANDRA-6746:
-------------------------------------
I assumed that the idea is to turn off read-ahead (using FADV_RANDOM) and to
always manage it ourselves. Which may well be an ok idea - but will require
some other changes. I must admit I don't quite follow all of what you're
saying: since we always buffer (except for mmapped files) 64K, WILLNEEDing the
entire block seems perfectly acceptable since we have to read it anyway (it
doesn't matter where the column occurs, unless it happens to be in a different
chunk).
I must admit I am left a smidgen generally concerned about the WILLNEED flag
and its implications for treatment of the page after the first use. I would
feel more comfortable dropping all uses of WILLNEED from the codebase, without
clearer definitions of the semantics, since we can probably do without them
after CASSANDRA-6916. But I don't feel so strongly about this.
bq. is keeping page cache for the old files creates more jitter and slows down
warmup of the newly created SSTable.
CASSANDRA-6916 should solve this problem.
> 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-buffered-io-tweaks.png,
> 6746-patched.png, 6746.blockdev_setra.full.png,
> 6746.blockdev_setra.zoomed.png, 6746.buffered_io_tweaks.logs.tar.gz,
> 6746.buffered_io_tweaks.write-flush-compact-mixed.png,
> 6746.buffered_io_tweaks.write-read-flush-compact.png, 6746.txt,
> buffered-io-tweaks.patch, 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)
