[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226516#comment-14226516
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
Some short notes about the last changes in OHC:
* changed from block-oriented allocation to Unsafe or JEMalloc (if available)
* added stamped locks in off-heap (quite simple and very efficient)
* triggering cleanup + rehash via cas-side trigger works fine
* extended the benchmark tool to specify different workload chacteristics
(read/write ratio, key distribution, value length distribution - distribution
code taken from cassandra-stress)
* still working on a good (mostly contention free) LRU strategy
One thing I noticed during benchmarking is that (concurrent?) allocations of
large areas (several MB) take up to 50/60ms (OSX 10.10, 2.6GHz Core i7 - no
swap, of course) - small regions are allocated quite fast (total roundtrip for
a put ~0.1ms for 98 percentile). It might be viable to implement some mixture
for memory allocation: Unsafe/JEMalloc for small regions (e.g. < 1MB) and
pre-allocated blocks for large regions. A configuration value could determine
the amount of large region blocks to keep immediately available. Just an idea...
> 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)
