[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275809#comment-14275809
]
Ariel Weisberg commented on CASSANDRA-7438:
-------------------------------------------
bq. Making freeCapacity a per-segment field: Then I'd prefer to "reverse" the
stuff - i.e. add an "allocatedBytes" field to each segment. Operations would
get the (calculated) free capacity as a parameter and act on that value. Or
were you thinking about dividing capacity by number of segments and use that as
the max capacity for each segment?
The goal of splitting the locks and tables into segments is to eliminate any
globally shared cache lines that are written to by common operations on the
cache. Having every put modify the free capacity introduces a potential point
of contention. Only way to really understand the impact is to have a good micro
benchmark you trust and try it both ways.
I think that you would split the capacity across the segments. Do exactly what
you are doing now, but do the check inside the segment. Since puts are allowed
to fail I don't think you have to do anything else.
bq. Regarding rehash/iterators: Could be simply "worked around" by counting the
number of active iterators and just don't rehash while an iterator is active.
That's better than e.g. returning duplicate keys or keys not at all - i.e.
people relying on that functionality.
This is an OHC not a C* issue. I think from C*'s perspective it can be wrong
rarely and it doesn't matter since it doesn't effect correctness. Definitely
worth documenting though.
bq. I lean towards removing the new tables implementation in OHC. It has the
big drawback that it only a allows a specific number of entries per bucket
(e.g. 8). But I'd like to defer that decision after some tests on a NUMA
machine.
You are on to something in terms of making a faster hash table, but it doesn't
seem like huge win given the short length of most chains (1, or 2) and the
overhead of the allocator and locking etc. It would show up in a
micro-benchmark, but not in C*. I would like to stick with linked for C* for
now since it's easy to understand and I've looked at it a few times.
I think I already sent you a link to this
https://www.cs.cmu.edu/~dga/papers/silt-sosp2011.pdf but there are a lot of
ideas there for dense hash tables. You can chain together multiple buckets so
the entries per bucket becomes a function of cache line size.
> 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: Robert Stupp
> Labels: performance
> Fix For: 3.0
>
> Attachments: 0001-CASSANDRA-7438.patch, tests.zip
>
>
> 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)
