[
https://issues.apache.org/jira/browse/CASSANDRA-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237749#comment-15237749
]
Branimir Lambov commented on CASSANDRA-11452:
---------------------------------------------
Thanks for the pointers!
Caffeine's looking pretty
[good|https://docs.google.com/spreadsheets/d/11VcYh8wiCbpVmeix10onalAS4phfREWcxE-RMPTM7cc/edit?usp=sharing].
Some questions:
-- With heavy cpu load it seems the maintenance thread doesn't get enough
chances to update, causing the cache to grow way beyond its intended size. I'm
solving the problem by configuring the executor to
{{MoreExecutors.directExecutor()}}. Is it a good idea to use this setting? Any
caveats (beyond slowing down caller threads on contention, which is somewhat
desirable for us)?
-- I would prefer to use the admission/eviction strategy on its own (I'm in the
process of converting to a separate map per file, sharing cache space and
eviction). If you have any pointers which parts of the library to use for that,
I'd be grateful.
-- More theoretically, I find it fascinating that bloom-filtered counting can
outperform explicit access tracking as in LIRS, but I have some worries about
potential issues with the long-term stability of the cache. The design suggests
that the cache will have a tendency to attract and retain hash collisions, i.e.
it looks as if in effect it will be actively looking for hash collisions of the
hot keys, and will want to keep those around forever. Could this be a real
problem / is there something I'm missing? (The [Einziger/Friedman
paper|http://www.cs.technion.ac.il/~gilga/TinyLFU_PDP2014.pdf] does not say
anything on this topic.)
> Cache implementation using LIRS eviction for in-process page cache
> ------------------------------------------------------------------
>
> Key: CASSANDRA-11452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11452
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Reporter: Branimir Lambov
> Assignee: Branimir Lambov
>
> Following up from CASSANDRA-5863, to make best use of caching and to avoid
> having to explicitly marking compaction accesses as non-cacheable, we need a
> cache implementation that uses an eviction algorithm that can better handle
> non-recurring accesses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
