cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10529) Channel.size() is costly, mutually exclusive, and on the critical path
Date Thu, 15 Oct 2015 08:50:05 GMT

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

Benedict commented on CASSANDRA-10529:
--------------------------------------

That is very strange, but given standard is as high as old mmap it's probably fine. We need
to fix the variability in cstar. For future reference, it's worth at least disabling vnodes
to ensure we have an identical cluster until cstar supports sets of predefined token rings.

I did not examine this exhaustively, but I saw a meaningful uptick (>20%) when profiling
a single node cluster after making this change. However that may have been down to interactions
with the specific profiler I was using at the time (which did require safe points), which
may have worsened the problem of mutual exclusivity. Either way, it's worth making.

> Channel.size() is costly, mutually exclusive, and on the critical path
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-10529
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10529
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Benedict
>            Assignee: Stefania
>             Fix For: 3.0.0 rc2
>
>
> [~stefania_alborghetti] mentioned this already on another ticket, but I have lost track
of exactly where. While benchmarking it became apparent this was a noticeable bottleneck for
small in-memory workloads with few files, especially with RF=1. We should probably fix this
soon, since it is trivial to do so, and the call is only to impose an assertion that our requested
length is less than the file size. It isn't possible to safely memoize a value anywhere we
can guarantee to be able to safely refer to it without some refactoring, so I suggest simply
removing the assertion for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message