cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7438) Serializing Row cache alternative (Fully off heap)
Date Tue, 04 Nov 2014 18:16:35 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196492#comment-14196492
] 

Vijay edited comment on CASSANDRA-7438 at 11/4/14 6:16 PM:
-----------------------------------------------------------

{quote}
 well I think you run into another issue which is that the ring buffer doesn't appear to check
for queue full? 
{quote}
Yeah i thought about it, we need to handle those and thats why didn't have it in the first
place. Should not be really bad though.
{quote}
I don't agree that Unsafe couldn't do the exact same thing with no on heap references
{quote}
Probably, since we figured most of the implementation detail sure we can but still there is
always many different ways to solve the problem (May not be very efficient to copy multiple
bytes to get to the next item in map etc... GC and CPU overhead would be more IMHO). For example
Memcached used expiration time set by the clients to remove the items which made it easier
for them to do the slab allocator but this is something we removed it in lruc and just a queue.
{quote}
I also wonder if splitting the cache into several instances each with a coarse lock per instance
wouldn't result in simpler
{quote}
The problem there is how will you invalidate the least used items, since they are different
partitions you really don't know which ones to invalidate... there is also a problem of load
balancing when to expand the buckets etc which will bring us back to the current lock stripping
solutions IMHO.

I can do some benchmarks if thats exactly what we need at this point.... Thanks!



was (Author: vijay2win@yahoo.com):
{quote}
 well I think you run into another issue which is that the ring buffer doesn't appear to check
for queue full? 
{quote}
Yeah i thought about it, we need to handle those and thats why didn't have it in the first
place. Should not be really bad though.
{quote}
I don't agree that Unsafe couldn't do the exact same thing with no on heap references
{quote}
Probably, since we figured most of the implementation detail sure we can but still there is
always many different ways to solve the problem (May not be very efficient to copy multiple
bytes to get to the next item in map etc... GC and CPU overhead would be more IMHO). For example
Memcached used expiration time set by the clients to remove the items which made it easier
for them to do the slab allocator but this is something we removed it in lruc and just a queue.
{quote}
I also wonder if splitting the cache into several instances each with a coarse lock per instance
wouldn't result in simpler
{quote}
The problem there is how will you invalidate the last used items, since they are different
partitions you really don't know which ones to invalidate... there is also a problem of load
balancing when to expand the buckets etc which will bring us back to the current lock stripping
solutions IMHO.

I can do some benchmarks if thats exactly what we need at this point.... Thanks!


> 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)

Mime
View raw message