cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
Date Wed, 23 Jul 2014 20:05:40 GMT


Vijay commented on CASSANDRA-7438:

for starters, the first 1s in each gives 10x the throughput, and each is then followed by
some weirdly lengthy random pauses. SerializingCacheProvider sees a 21s latency pause
Not sure about which 21 second pause, are you talking about thread creation takes time specially
during startup?
Anyways yes when the concurrency is lower here is the

The SerializingCacheProvider actually has higher total throughput as well
Obviously the overhead will be more because now we are serializing the row key also off heap
and there is safe points when calling JNI, but Let me clarify the goal for the patch is not
to run OOM when the cache size is bigger than the heap.
If interested i can run some benchmarks to show that.

Is this all over CQL3 native
Yep it is thrift, and here is CQL3 w/ prepared.

> 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