[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073352#comment-14073352
]
Vijay commented on CASSANDRA-7438:
----------------------------------
Hi Jonathan, The win is that we can now have Caches which can be bigger than
JVM with zero GC overhead on the items. Unsafe approach will hold the
references in memory and the overhead on them is reasonably high compared to
the native approach (example of it is an integer key's) and in addition if we
use hash map we have segments with locks (also there the references in the
queue), so it is not a straight forward approach either.
Having said that, the only approach i can think of is that we can go about
allocating a Huge Unsafe memory in one shot and do something like a btree
traverse inside and hold locks accordingly (or wait till java has off heap hash
map, but we still didn't solve the eviction problem), the approach we have
taken in lruc is not that complex either. As Robert mentioned we need more
testing on different flavors of the environment and hence i made it
configurable.
Hi Robert, Added you in the project and no i did not try the maven plugin
(looking forward), thanks!
{quote}
did you try different malloc implementations
{quote}
we can change to jemalloc pretty easily CASSANDRA-3997, thats my next test.
{quote}
next instruction do two JNI calls
{quote}
For this i was thinking of replacing it with unsafe.memoryAllocate instead and
replicate what we do with lruc_item_allocate().
Thanks!
> 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)
