[
https://issues.apache.org/jira/browse/CASSANDRA-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14526647#comment-14526647
]
T Jake Luciani commented on CASSANDRA-9240:
-------------------------------------------
[~benedict] you have a bug in the CRAR constructor. allocateBuffer() is being
called before segments are mapped so it is always creating an on heap buffer.
Minor nit in your Cleanup method. For multiple levels of conditionals and loops
please add {}
Finally, I know CASSANDRA-8897 is going to remove pooling, but how will we
avoid the cost of un-mapping the files if we don't pool?
> 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: Benedict
> Priority: Minor
> Fix For: 3.x
>
> 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, runs.log,
> 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)
