[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263083#comment-14263083
]
Ariel Weisberg commented on CASSANDRA-7438:
-------------------------------------------
I went to run the benchmark myself and I noticed you used a uniform
distribution for the keys. I don't think that makes sense for testing a cache
where the primary benefit is going to be from cacheable access patterns. I
would use extreme with .6 or .5 for the shape.
I am also confused by the benchmark implementation. There are threads
generating the tasks and then handing them off to other threads for execution.
This means the benchmark is measuring unrelated things like the performance of
the queue used for receiving tasks and returning results as well as the general
design of the harness. It makes me wonder if that is the source of the
under-utilization issue.
I think this might work well as a JMH benchmark and the parameterization would
make it easy to put together a full test matrix that anyone can run with one
command.
I tried to run it and it seems to go for longer than expected. I specified -d
300 and it is still going. The benchmark is doing work according to top.
I ran on a c3.8xlarge using the Rightscale 14.1 base server template running
Ubuntu 14.04, Oracle JDK8u25, I got jemalloc from the libjemalloc1 package.
Cloned OHC today and ran the benchmarking using
bq.java -jar ohc-benchmark/target/ohc-benchmark-0.2-SNAPSHOT.jar -rkd
'gaussian(1..20000000,2)' -wkd 'gaussian(1..20000000,2)' -vs
'gaussian(1024..4096,2)' -r .9 -cap 16000000000 -d 300 -t 30 -dr 8
after running "mvn package".
> 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, 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)
