[
https://issues.apache.org/jira/browse/CASSANDRA-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14516958#comment-14516958
]
Benedict commented on CASSANDRA-9240:
-------------------------------------
bq. Could it be that the OS is evicting memory-mapped pages
No, definitely not. But you're on the right track. I'm pretty sure the problem
is that we explicitly "clean" the buffers on "deallocating" the RARs. If the
reader is memory-mapped this likely results in the OS evicting at least those
pages (perhaps more?)
Reassigning to [~tjake] since this is a problem from CASSANDRA-8464 itself, and
not the new lz4 methods.
> Performance issue after a restart
> ---------------------------------
>
> Key: CASSANDRA-9240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9240
> Project: Cassandra
> Issue Type: Bug
> Reporter: Alan Boudreault
> Assignee: Branimir Lambov
> Fix For: 3.0
>
> Attachments: Cassandra.snapshots.zip,
> cassandra_2.1.4-clientrequest-read.log, cassandra_2.1.4.log,
> cassandra_2.1.5-clientrequest-read.log, cassandra_2.1.5.log,
> cassandra_trunk-clientrequest-read.log, cassandra_trunk.log,
> cassandra_trunk_no_restart-clientrequest-read.log,
> cassandra_trunk_no_restart.log, issue.yaml, run_issue.sh, trace_query.cql
>
>
> I have noticed a performance issue while I was working on compaction perf
> tests for CASSANDRA-7409. The performance for my use case is very bad after a
> restart. It is mostly a read performance issue but not strictly. I have
> attached my use case (see run_issue.sh and issue.yaml) and all test logs for
> 2.1.4, 2.1.5 and trunk:
> * 2.1.* are OK (although 2.1.4 seems to be better than 2.1.5?): ~6-7k
> ops/second and ~2-2.5k of read latency.
> * trunk is NOT OK: ~1.5-2k ops/second and 25-30k of read latency.
> * trunk is OK without a restart: ~ same perf than 2.1.4 and 2.1.5.
> EDIT: branch cassandra-2.1 is OK.
> I can help to bisect and/or profile on Monday if needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
