cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
Date Wed, 26 Nov 2014 00:30:13 GMT

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

Ariel Weisberg edited comment on CASSANDRA-7438 at 11/26/14 12:29 AM:
----------------------------------------------------------------------

bq. if we don't like the constant overhead of the cache in heap and If you are talking about
CAS which we already do for ref counting, as mentioned before we need an alternative strategy
for global locks for rebalance if we go with lock less strategy.
Just take what you have and do it off heap. You don't need to change anything about how locking
is done, just put the segments off heap so each segment would be a 4-byte lock field and an
8 byte pointer to the first entry. I am not clear on the alignment requirements for 4 or 8
byte CAS.

bq. Until you complete a rehash you don't know if you need to hash again or not... Am i missing
something?
https://github.com/Vijay2win/lruc/blob/master/src/main/java/com/lruc/unsafe/UnsafeConcurrentMap.java#L38

The check on line 38 races with the assignment on line 39. N threads could do the check and
think a rehash is necessary. Each would submit a rehash task and the table size would be doubled
N times instead of 1 time.


was (Author: aweisberg):
bq. if we don't like the constant overhead of the cache in heap and If you are talking about
CAS which we already do for ref counting, as mentioned before we need an alternative strategy
for global locks for rebalance if we go with lock less strategy.
Just take what you have and do it off heap. You don't need to change anything about how locking
is done, just put the segments off heap so each segment would be a 4-byte lock field and an
8 byte pointer to the first entry.

bq. Until you complete a rehash you don't know if you need to hash again or not... Am i missing
something?
https://github.com/Vijay2win/lruc/blob/master/src/main/java/com/lruc/unsafe/UnsafeConcurrentMap.java#L38

The check on line 38 races with the assignment on line 39. N threads could do the check and
think a rehash is necessary. Each would submit a rehash task and the table size would be doubled
N times instead of 1 time.

> Serializing Row cache alternative (Fully off heap)
> --------------------------------------------------
>
>                 Key: CASSANDRA-7438
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7438
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: Linux
>            Reporter: Vijay
>            Assignee: Vijay
>              Labels: performance
>             Fix For: 3.0
>
>         Attachments: 0001-CASSANDRA-7438.patch
>
>
> Currently SerializingCache is partially off heap, keys are still stored in JVM heap as
BB, 
> * There is a higher GC costs for a reasonably big cache.
> * Some users have used the row cache efficiently in production for better results, but
this requires careful tunning.
> * Overhead in Memory for the cache entries are relatively high.
> So the proposal for this ticket is to move the LRU cache logic completely off heap and
use JNI to interact with cache. We might want to ensure that the new implementation match
the existing API's (ICache), and the implementation needs to have safe memory access, low
overhead in memory and less memcpy's (As much as possible).
> We might also want to make this cache configurable.



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

Mime
View raw message