[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275047#comment-14275047
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
Thanks for the review. Many useful hints in it :)
I'll reduce configuration stuff in C* integration as suggested and add some
default-by-system-property mechanism (as suggested).
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?
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.
I just started JMH without any additional parameters. It's called during Maven
test phase (unless you specify -DskipTests).
You're right. Murmur3 + UTF8 need more tests.
Didn't notice that that fastutil is that fat. Already replaced with an own
implementation.
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.
> 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)
