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

Matt Stump commented on CASSANDRA-8833:
---------------------------------------

I'm not against refactoring of SSTableReader, I think it's overly complicated, 
but I also think that the fix being proposed is overly complicated. You can't 
get away from OS specific code because the code to manage the file system cache 
is OS specific. The trySkipCache logic in CLibrary is currently specific to 
Linux. I've slightly broadened it to Linux and some BSD variants (excluding 
OSX) in my patch for CASSANDRA-8160. We can get the desired behavior for 
Windows through selective use of the SEC_NOCACHE flag when opening the memory 
mapped file for windows, but that would require pushing the cache advisory 
logic one lower deeper. I don't think switching to an NIO channel will 
alleviate us from the need to provide hints to the OS of which IO is or is not 
appropriate to cache.

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

Reply via email to