[
https://issues.apache.org/jira/browse/CASSANDRA-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935922#comment-13935922
]
Pavel Yaskevich commented on CASSANDRA-6746:
--------------------------------------------
bq. judging by how severe the slow down is you're probably correct, however
that only changes the shape of the slope (should make it a considerably longer
slow period, but much less slow), it doesn't eliminate the effect. We should be
managing our cache behaviour better either way.
Well, I wasn't even implying that changing read-ahead on blockdev would
eliminate the effect described here, but it would only smoothen the effect of
the cold page cache. The things I asked Ryan to do is just to check if that's
the case, when it pretty much looks like it is.
bq. Not sure exactly what you're referring to here; fsync trickle is off by
default, and dirty data will always evict clean data. IF we trickle fsync,
DONTNEED may well help to reduce cache churn by causing us to recycle the same
approximate allotment of memory for flushing, which is what I'm suggesting -
but we don't currently, so all DONTNEED achieves is trashing the buffer as we
approach fully flushed, it doesn't make room for flushing.
What I mean here - with fsync trickle enabled DONTNEED reduces the amount of
housekeeping kernel has to for page cache especially in the write-heavy use
case like this test.
bq. Also, on POSIX_FADV_RANDOM: I experimented with settings this using
CLibrary we use for DONTNEED etc, and found performance actually degraded on my
machine for a stress read workload interestingly.
I'm not sure how are you doing that, can you elaborate? it's only possible to
set POSIX_FADV_RANDOM when disk_access_mode is "standard" in yaml, by default
we use we do mmap which requires us to do madvice for RANDOM instead of
fadvice, so your slowdown is kind of expected there.
> 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)
