cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Wed, 04 Dec 2013 05:51:36 GMT

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

Vijay commented on CASSANDRA-5549:
----------------------------------

{quote}
Without switch lock, we won't have anything preventing writes coming through when we're over-burdened
with memory use by memtables.
{quote}
I should be missing something, how does the switch RW Lock to a kind of CAS operation change
this schematics?
Are we talking about additional requirement/enhancements to this ticket?

{quote}
 When we flush a memtable we release permits equal to the estimated size of each RM
{quote}
IMHO, that might not be good enough since Java's memory over head is not considered. And calculating
the object size is not cheap either....

> Remove Table.switchLock
> -----------------------
>
>                 Key: CASSANDRA-5549
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5549
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>              Labels: performance
>             Fix For: 2.1
>
>         Attachments: 5549-removed-switchlock.png, 5549-sunnyvale.png
>
>
> As discussed in CASSANDRA-5422, Table.switchLock is a bottleneck on the write path. 
ReentrantReadWriteLock is not lightweight, even if there is no contention per se between readers
and writers of the lock (in Cassandra, memtable updates and switches).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message