[
https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838782#comment-13838782
]
Benedict commented on CASSANDRA-5549:
-------------------------------------
bq. how does the switch RW Lock to a kind of CAS operation change this
schematics?
In forceFlush() we obtain the writeLock, but do not relinquish it until we have
successfully added to the flushWriters queue. The flushWriters queue length
also configures how often we should flush, so that once it is full, we are
effectively "out of memory". This is hardly a *precise* mechanism for memory
control, but it is the one we currently use, and it definitely needs a
replacement.
bq. 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....
I don't see your concerns here? We can easily and cheaply calculate the costs -
we precompute the overheads, and simply apply them on a per row and per key
basis. The overheads are pretty fixed for both - for SnapTreeMap they're
exactly the same for each key, and with CASSANDRA-6271 they are relatively
easily computable (or simply countable, in log(32,N) time - probably I will opt
for computing first, then counting after insertion to get exact amount used).
Java's memory overhead is included in any calculation.
> Remove Table.switchLock
> -----------------------
>
> Key: CASSANDRA-5549
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5549
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Benedict
> 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)
