[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14284416#comment-14284416
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
bq. I am +1 conditional on the library throwing OOME if the allocator fails.
Will add a configuration switch to explicitly enable this behavior.
bq. There are also still some internal properties inside OHC that are don't
have a prefix.
Yes, debug-mode and disable-jemalloc did not had the prefix. Will be changed.
bq. I noticed you fixed some C* bugs ... need to be backported?
It's only the {{==}} to {{equals}} change in
{{ColumnFamilyStore.cleanupCache}}. It's not necessary to fix it for older
versions, since the {{UUID}} instance is taken from {{CFMetaData}} - so the
{{==}} is (was) correct.
bq. Can you publish a new version to maven central so I can benchmark it vs the
old cache implementation?
OHC 0.3 + 0.3.1 are on Maven Central.
Note: OHC 0.3.1 incorporates the changes above (might not found using Maven
Central search, but artifacts are there)
C* git branch updated to use 0.3.1
> 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)
