cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
Date Wed, 26 Nov 2014 17:41:13 GMT


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:
>             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
> * 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

View raw message