cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
Date Sat, 01 Nov 2014 02:26:34 GMT


Pavel Yaskevich commented on CASSANDRA-7438:

I looked trough the patch and everything looks good, but one small thing:

- FBUtilities.newRowCacheProvider needs it's argument renaming, because it looks like it has
been copied from FBUtilities.newPartitioner and has old names, so instead of paritioner it
should be rowCacheClassName and "rowCache" as the last argument for FBUtilities.construct(...).

I just want to address Robert's comment regarding EncodedData{Input/Output}Stream: I agree
that longs returned by version 1 UUID are not that compressible and vint is actually going
to add 1 byte on top of long (which is pretty easy to test), but the good thing is that although
we loose 2 bytes in long serialization we actually win back at least 2 bytes by vint encoding
length of the key and, in best case, if key size is less than 127 (which is highly likely)
we are actually going to win 3 bytes which makes in total 1 byte profit from encoding :)


> 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