[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240193#comment-14240193
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
bq. Lot's of cool stuff
Thx :)
Unit testing: you are absolutely right. (Will go on with that next)
bq. unit test that fuzzes against a parallel implementation at the same time
using a different LRU map implementation
Do you mean sth. like LinkedHashMap with removeEldestEntry() ? It's some effort
to get a "nice" implementation for unit tests - but, yeah - makes sense.
bq. duplicates reference counting code
removed duplicated code
bq. cleanup/eviction code go away ... remove entries until it [fits]
much easier ; cleaner code ; implemented - but not completely sold on the new
implementation yet (quick hack yet)
bq. C* cache interface ... get compression and more efficient IO [later]
That's fair. I just saw some minutes ago that row-cache serialization "only"
persists the keys and not the values - so the existing implementation in OHC
would need to be changed / extended / whatever. I thought it persists the
value, too.
> 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, tests.zip
>
>
> 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)
