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-8833) Stop opening compaction results early
Date Thu, 19 Feb 2015 19:54:12 GMT

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

Benedict commented on CASSANDRA-8833:
-------------------------------------

bq. there may be unintended side-effects to some of those changes

I have no doubt, which is partially why I consider this premature. We had a period of problems
(not isolated to this, I want to reiterate), and we've had a very recent attempt to put them
to bed. But not let that settle down to see how successful it has been. I'm expecting a few
more minor hiccups. If we see some more major ones, especially regressions, that's a different
matter.

bq. Thus far we've avoided platform-specific code-paths as much as possible, but that seems
a simple enough solution that it would be worth looking into.

I'd actually be totally cool with (and maybe even prefer) making this a universal behaviour.
That way we don't have multiple mappings of the same file, and we still retain most of the
upside, with no behavioural split.

> Stop opening compaction results early
> -------------------------------------
>
>                 Key: CASSANDRA-8833
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8833
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Marcus Eriksson
>             Fix For: 2.1.4
>
>
> We should simplify the code base by not doing early opening of compaction results. It
makes it very hard to reason about sstable life cycles since they can be in many different
states, "opened early", "starts moved", "shadowed", "final", instead of as before, basically
just one (tmp files are not really 'live' yet so I don't count those). The ref counting of
shared resources between sstables in these different states is also hard to reason about.
This has caused quite a few issues since we released 2.1
> I think it all boils down to a performance vs code complexity issue, is opening compaction
results early really 'worth it' wrt the performance gain? The results in CASSANDRA-6916 sure
look like the benefits are big enough, but the difference should not be as big for people
on SSDs (which most people who care about latencies are)
> WDYT [~benedict] [~jbellis] [~iamaleksey] [~JoshuaMcKenzie]?



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

Mime
View raw message