[
https://issues.apache.org/jira/browse/CASSANDRA-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935903#comment-13935903
]
Benedict commented on CASSANDRA-6746:
-------------------------------------
[~xedin] 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.
bq. with WONTNEED'ing all of the compacted sstables and newly flushed ones we
create more room for durty data which smoothens fsync trickle effect.
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.
I realised I actually have fincore data Ryan collected for me from these runs
that demonstrates large files being flushed with DONTNEED still retain a
majority of their data in page cache during the flush, presumably for exactly
the reason given of racing-ahead writes. Then lose it all completely:
{code}
File Size Cached Perc
Keyspace1-Standard1-tmp-ka-109-Data.db 391,446,528 230,858,752 58.98
Keyspace1-Standard1-tmp-ka-109-Data.db 1,062,600,704 470,552,576 44.28
Keyspace1-Standard1-tmp-ka-109-Data.db 1,467,744,256 681,713,664 46.45
Keyspace1-Standard1-tmp-ka-109-Data.db 2,068,840,448 860,418,048 41.59
Keyspace1-Standard1-tmp-ka-109-Data.db 2,402,760,276 1,026,052,096 42.70
Keyspace1-Standard1-ka-109-Data.db 2,402,760,276 113,348,608 4.72
{code}
> 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)
