[jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)

["Vijay (JIRA)" <ji...@apache.org>]

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

Vijay commented on CASSANDRA-7438:
----------------------------------

Thanks Robert, Pushed the fix for 1 and 2. 
{quote}
Utils.md5sum() should use thread local instances of MessageDigest
{quote}
Md5 is fine since this happens only when initialized for the first time when the cache is initialized and it should be fine.

{quote}
the mechanism to extract the so/dylib is a bit error prone since all JVM instances use the same path name. 
{quote}
IMHO, Its a safe assumption that we don't support multiple versions on the same physical box (of the library) on the same machine at the same time.

{quote}
counters/timers in C code to track global locks
{quote}
NOTE: this is only during the hash table expansions. (not during steady state)
Created a ticket to track it in the near future... May want to do something little fancy like Yammer Metrics

{quote}
"used>highWaterMark", where highWaterMark is for example 80% of max
{quote}
I initially tried with the queue thread, to keep track of usage and expire proactively, but I had to involves a global lock and we might end up over committing memory, so may be in the future. (Current implementation works similar to CLHM)

> 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
>
>
> 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)