[ 
https://issues.apache.org/jira/browse/CASSANDRA-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14524374#comment-14524374
 ] 

Benedict commented on CASSANDRA-9240:
-------------------------------------

OK, so I've pushed a fix for this 
[here|https://github.com/belliottsmith/cassandra/tree/9240]

This both reintroduces the pooling, and shares the mapped segments between all 
readers, for both pooled and regular compressed files. This could be tidied up, 
but since we're eliminating a lot of the functionality in these classes in the 
near future time is probably better spent cleaning them up as that happens.

FTR, I managed to reproduce the problem with a regular heap with mmap enabled 
on trunk, and could eliminate the problem without reintroducing pooling, at 
least with those heap settings. So the cleaning of the buffers was likely the 
main culprit. I could strangely reproduce some reduced throughput on trunk with 
standard mode without pooling vs with, but not on my branch. That's a little 
odd, but probably a rabbit hole not worth diving into.

> 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)

Reply via email to