cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6746) Reads have a slow ramp up in speed
Date Fri, 14 Mar 2014 23:02:48 GMT


Benedict commented on CASSANDRA-6746:

I will do some empirical testing so we have some data to work with. It seems to me that "trickle"
flushing would still be better than this, although we could still DONTNEED after trickle sync
for compaction. WILLNEEDing a large file _after flush_ is potentially even worse behaviour,
though, as if the DONTNEED has been obeyed (or they've fallen out of cache due to not being
read during flush - which is probably likely during a large flush) we're just proactively
inducing a period of high intensity random seeks for data that would naturally be read in
anyway if they are needed, and otherwise would not.

That said, it might be easier to just pick an approach (the one you suggest is certainly better
than what we currently do), and then deliver iterative replacement, as it solves all of the
above problems.

> Reads have a slow ramp up in speed
> ----------------------------------
>                 Key: CASSANDRA-6746
>                 URL:
>             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,
> 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|]

This message was sent by Atlassian JIRA

View raw message