[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072361#comment-14072361
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
Some minor notes:
*
https://github.com/Vijay2win/lruc/blob/master/src/main/java/com/lruc/api/LRUCache.java#L58
calls keySerializer.serializedSize(key) twice
*
https://github.com/Vijay2win/lruc/blob/master/src/main/java/com/lruc/api/LRUCache.java#L58
+ next instruction do two JNI calls. Maybe it gains some performance to pass
a {{new long[2]}} to a (new) {{lrucJNI.lruc_items_alloc}} method that allocates
memory for two items (saves one JNI savepoint)
To implement full off-heap in Java would require our own memory management or
usage of an offheap management lib (couldn't find any straightaway). The only
projects I know that have "flexible" memory off-heap allocation are netty and
grizzly - but I don't know how they perform.
Integration tests should be done on most important platforms like Linux x64,
OSX, Win64. I think we can omit 32 bit platforms. I can help testing it on OSX
and Win if needed.
There should be a "standardized" test that aggressively uses off-heap data
(put, get, replace, putIfAbsent, etc) using some threads (not too many - maybe
2xCPU-cores).
[[email protected]] - did you try different malloc implementations?
> 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.2#6252)
