[
https://issues.apache.org/jira/browse/CASSANDRA-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935844#comment-13935844
]
Pavel Yaskevich commented on CASSANDRA-6746:
--------------------------------------------
[~iamaleksey] asked me to look at this ticket, so here is what I have - this
very much looks like readahead is killing the performance on random access with
empty page cache, unfortunatelly we don't set POSIX_FADV_RANDOM as there is no
way to do it from Java with mmap'ed files... So [~enigmacurry] what you can do
to check if it's actually the reason - try getting current readahead window
with "blockdev -getra <device>" to see how big it currently is (should be
something like 256 which is 128KB), set it to something lower or disable at all
with "blockdev --setra <readahead-size-in-512-byte-blocks> <divice>", note (!)
that both of the commands return value in multiple of 512-byte blocks. After
that is done, try running your test again to see if the read performance
increases more rapidly. The situation you are triggering is kind of an edge
case which is caused by us trying to be smart about discarding things that we
no longer need in memory, so when writes are done in isolation it's natural
that reads that are going to suffer consequences but on the bright side with
WONTNEED'ing all of the compacted sstables and newly flushed ones we create
more room for durty data which smoothens fsync trickle effect.
> 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)
