[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14047491#comment-14047491
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
Cool :)
Just some minors - maybe irrelevant:
- there's a typo in LRUCache : getPoniterOfPointer
- LRUCache.put() should not use putIfAbsent() just to omit the deserialization
which is unneccessary for put()
- Utils.md5sum() should use thread local instances of MessageDigest
- the mechanism to extract the so/dylib is a bit error prone since all JVM
instances use the same path name. Maybe it's easier to inquire a temp file name
from File.createTempFile (necessary to use the stuff on micros... boxes) and
delete the so/dylib file on process exit (which does not work on ms boxes).
- counters/timers in C code to track global locks (e.g.
assoc_maintenance_thread() - item_(un)lock_global ) could be useful to track
stress/performance tests
- may_expire() is invoked on "each" call (expires entries, as long as
used>max). If the cache is full, the method will work for nearly each cache
call. Would it be an option to let it start work, if "used>=max" and work until
"used>highWaterMark", where highWaterMark is for example 80% of max? Or to
"trigger" an eviction run in the maintenance thread so that "user" code is not
affected and mutex locks in max_expire are not necessary?
> 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)
