[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195679#comment-14195679
]
Vijay commented on CASSANDRA-7438:
----------------------------------
Thanks for reviewing!
{quote}
I am also not clear on why locks are necessary for individual items.
{quote}
No we don't. We have locks per Segment, this is very similar to lock stripping
or the smiler to Java's concurrent hash map.
{quote}
global lock in may_expire() quite frequently?
{quote}
Not really we lock globally when we reach 100% of the space and we freeup to
80% of the space and we spread the overhead to other threads based on who ever
has the item partition lock. It won't be hard to make this part of the queue
thread and will try it for the next release of lruc.
{quote}
What kind of hardware was the benchmark run on?
{quote}
32 core 100GB RAM with numa and intel xeon. There is a benchmark util which is
also checked in as a part of the lruc code which does exactly the same kind of
test.
{quote}
You really need a plan for running something like Valgrind
{quote}
Good point, I was part way down that road and still have the code i can
resuruct it for the next lruc version.
{quote}
I am not clear on why the JNI is justified
{quote}
There is some comments above which has the reasoning for it (please see the
above comments). PS: I believe there was some tickets on Current RowCache
complaining about the overhead.
{quote}
I think JNI would make more sense if we were pulling in existing code like
memcached
{quote}
If you look at the code closer to memcached. Actually I started of stripping
memcached code so we can run it in process instead of running as a separate
process and removing the global locks in queue reallocation etc and eventually
diverged too much from it. The other reason it doesn't use slab allocators is
because we wanted the memory allocators to do the right thing we already have
tested Cassandra with Jemalloc.
To confort a bit lruc is running in our production already :)
> 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.3.4#6332)
