[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-7438:
-----------------------------
Attachment: tests.zip
Hi Jonathan, We should at least make the cache more pluggable with this ticket.
{quote}Well, it can, but it's almost always a bad idea. Not something we should
optimize for.{quote}
Just my 2 cents: I have seen some use cases which store bigger blobs as column
values too...
Sorry to diverge the discussion again. Alright, completed most of the items in
this ticket.
* Expiry thread to proactively remove items (looks like it catches up withe
load pretty well).
* Some minor comments on metrics and a bit of refactor. (will have to revisit
all the discussion again)
* Some error handling and additional tests.
Looks like lruc JNI based and Unsafe are close to each other. Numbers
attached...
* The difference is that unsafe is performing worse at P99 distributions and C
implementation at P999.
* I think the performance hit on both caches are during rehash global locks.
* Note these numbers are in my laptop and during the run's CPU's are 100% so
might not be perfect.
* Will have to run benchmark on server grade (big memory) machines on Monday.
> 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)
