[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222660#comment-14222660
]
Pavel Yaskevich commented on CASSANDRA-7438:
--------------------------------------------
Personally I like what Vijay did a bit more just because main ideas where taken
from the memcached which is proven to be working fine for the majority of the
use-cases and is pretty simple inside.
Regarding Robert's implementation I have few comments which he'll have to
address (if not already) before I would consider this for inclusion:
- rehashing is must have, we want to grow/shrink caches based on usage to
lessen burden on users trying to size it appropriately from day 1;
- if "put" operation fails it should at least invalidate previously inserted
value if any, and probably kick-off maintenance activities like LRU cleanup
and/or rehashing;
- Fixed size data block create a lot of allocation "slop" which could be
sometimes take majority of allocate memory (e.g. Firefox had that problem),
cache should at least have blocks of different sizes to minimize that;
- would be great to have benchmarks for per-partition CAS vs. per-partition RW
lock in different operation modes, cache invalidation could be noticeable
factor for performance as well as CAS-races;
- metrics (if not yet added).
Also based on discussion [~snazy] had with [[email protected]], I would
avoid using DirectByteBuffer because they are a problematic to GC.
> 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)
