[
https://issues.apache.org/jira/browse/CASSANDRA-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514169#comment-14514169
]
Benedict commented on CASSANDRA-9240:
-------------------------------------
If you could grab a profile (sampled time in each method) of each situation, it
could help. I would guess the problem is triggered by the creation of an
sstable after commit log replay, but exactly where the increased costs are
being incurred (on merge, on sstable read, whatever) is tough to say.
> 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
> Fix For: 3.0
>
> Attachments: cassandra_2.1-clientrequest-read.log,
> 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_2.1.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, cassandra-2.1 and trunk.
> 2.1.4 and 2.1.5 are OK (although 2.1.4 seems to be better?): ~6-7k ops/second
> and ~2-2.5k of read latency.
> branch 2.1 and trunk are NOT OK: ~1.5-2k ops/second and 25-30k of read
> latency.
> branch 2.1 and trunk are OK without a restart: ~ same perf than 2.1.4 and
> 2.1.5.
> I can help to bisect and/or profile on Monday if needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
