[jira] [Commented] (CASSANDRA-10529) Channel.size() is costly, mutually exclusive, and on the critical path
[ https://issues.apache.org/jira/browse/CASSANDRA-10529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14960295#comment-14960295 ] Benedict commented on CASSANDRA-10529: -- No, I'll commit this alongside the other small patches we have queued. > 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)
[jira] [Commented] (CASSANDRA-10529) Channel.size() is costly, mutually exclusive, and on the critical path
[ https://issues.apache.org/jira/browse/CASSANDRA-10529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14960139#comment-14960139 ] Stefania commented on CASSANDRA-10529: -- I agree it's definitely worth removing the assertion. Is there anything else you require for this ticket? > 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)
[jira] [Commented] (CASSANDRA-10529) Channel.size() is costly, mutually exclusive, and on the critical path
[ 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)
[jira] [Commented] (CASSANDRA-10529) Channel.size() is costly, mutually exclusive, and on the critical path
[ https://issues.apache.org/jira/browse/CASSANDRA-10529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958281#comment-14958281 ] Stefania commented on CASSANDRA-10529: -- I've removed the assertion, see patch attached. h5. CI http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10529-3.0-dtest/ http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10529-3.0-testall/ h5. cstar comparison http://cstar.datastax.com/graph?command=one_job&stats=b38f2330-72ec-11e5-8625-0256e416528f&metric=op_rate&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=44&ymin=0&ymax=161867.2 http://cstar.datastax.com/graph?command=one_job&stats=9279e6e0-72f0-11e5-a177-0256e416528f&metric=op_rate&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=43.01&ymin=0&ymax=167997.5 I think the gains must be below the variance of cstar or there must be an issue with the test parameters or environment; the patched mmap performs worse in both cases but it shouldn't since we just removed an assertion. > 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)
[jira] [Commented] (CASSANDRA-10529) Channel.size() is costly, mutually exclusive, and on the critical path
[ https://issues.apache.org/jira/browse/CASSANDRA-10529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958021#comment-14958021 ] Stefania commented on CASSANDRA-10529: -- I mentioned it in the first bullet point of [this comment|https://issues.apache.org/jira/browse/CASSANDRA-10407?focusedCommentId=14943083&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14943083] on CASSANDRA-10407. > 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 > 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)
