cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6919) Use OpOrder to guard sstable references for reads, instead of acquiring/releasing references
Date Tue, 22 Apr 2014 05:17:15 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Ellis updated CASSANDRA-6919:
--------------------------------------

    Reviewer: Marcus Eriksson

[~krummas] to review

> Use OpOrder to guard sstable references for reads, instead of acquiring/releasing references
> --------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6919
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6919
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>              Labels: performance
>             Fix For: 2.1 beta2
>
>
> To slightly improve CASSANDRA-6916, and because it's a bit of a simplification anyway,
we should move to ensuring sstable resources remain around during reads by guarding them with
an OpOrder (which is also being introduced for CASSANDRA-6694) instead of using markReferenced()/release.
> Note this does not eliminate markReferenced, as for long running processes such as compaction
it makes sense to have an independent mechanism, because these long running processes would
prevent all resource cleanup for their duration rather than just the resources they're using.

> All this does is cleanup and slightly optimise the read path, whilst giving better guarantees
about resource cleanup (e.g. page cache dropping of old sstables which may have been replaced
multiple times since the reader was created, so we are dropping pages we don't realise are
still in use - in real terms it should be very rare for such a reader to outlive multiple
replacements and this is only a performance issue, not a matter of correctness, but it's nice
to absolutely be certain anyway).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message