[ https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231878#comment-14231878 ]
Vijay edited comment on CASSANDRA-7438 at 12/2/14 8:31 PM: ----------------------------------------------------------- EDIT: Here is the explanation. run the benchmark with the following options (lruc benchmark). {code}java -Djava.library.path=/usr/local/lib/ -jar ~/lrucTest.jar -t 30 -s 6147483648 -c ohc{code} And you will see something like this (errors == not found from the cache even though you have all the items you need is in the cache). {code} Memory consumed: 3 GB / 5 GB or 4288887170 / 6147483648, size 49999980, queued (LRU q size) 0 VM total:2 GB VM free:2 GB Get Operation (micros) time_taken, count, mean, median, 99thPercentile, 999thPercentile, error 4734724, 1666666, 2.42, 1.93, 8.58, 24.74, 1666666 4804375, 1666666, 2.40, 1.92, 4.56, 106.23, 1666666 4805858, 1666666, 2.45, 1.95, 3.94, 11.76, 1666666 4842886, 1666666, 2.40, 1.92, 7.46, 26.73, 1666666 {code} You really need test cases :) Anyways i am going to stop working on this ticket now, let me know if someone wants any other info. was (Author: vijay2...@yahoo.com): Never mind, my bad it was related the below (which needs to be more configurable instead) and the items where going missing earlier than i thought it should and looks you just evict the items per segment (If a segment is used more more items will disappear from that segment and the lest used segment items will remain). {code} // 12.5% if capacity less than 8GB // 10% if capacity less than 16 GB // 5% if capacity is higher than 16GB {code} Also noticed you don't have replace which Cassandra uses. Anyways i am going to stop working on this for now, let me know if someone wants any other info. > 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)