[
https://issues.apache.org/jira/browse/CASSANDRA-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237796#comment-15237796
]
Ben Manes commented on CASSANDRA-11452:
---------------------------------------
h5. Heavy CPU
This only occurs in synthetic stress tests where there is no spare CPU cycles
for the maintenance thread. Cassandra's current LRU cache (via CLHM) has the
same general design and we've never encountered an issue in practice. In my
[stress
test|https://github.com/ben-manes/caffeine/blob/master/caffeine/src/test/java/com/github/benmanes/caffeine/cache/Stresser.java]
a simple `Thread.yield()` to mimic other system behavior showed this not to be
a problem. Without seeing your benchmark my analysis is that its not a
real-world issue. I do plan on someday switching to a bounded array-based queue
which would throttle the writes and produce a little less garbage (no linked
nodes), but its been low priority given the data I have so far.
Using a direct executor is fine, as it amortizes the penalty on the caller.
That's what CLHM (and Guava) do. In JDK8 we have the shared FJP so we can
reduce the variability of response times by offloading this work. Unlike CLHM
(and Guava), this setting would unfairly burden the evicting thread with
processing removal notifications if a removal listener is defined (the others
publish to a queue and try to share the penalty). A direct executor wouldn't
fix the problem as still one thread is overwhelmed by others, but penalizes to
reduce the insertion rate so it could only appear to help.
h5. Independent admission / eviction strategy
I'm not very clear on what you want here. If want to reimplement some of this
yourself then take a look at the [frequency
sketch|https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/com/github/benmanes/caffeine/cache/FrequencySketch.java].
h5. Long-term stability of the cache
The reset interval is used for aging the sketch(es) and multiple hashes should
reduce the error rate. The SLRU's probation space also allows mispredictions to
quickly fade out. It also only compares the candidate and victim, so a hot
entry would probably not be selected as a victim by the eviction policy. The
sketch uses a random seed to protect against hash flooding attacks, which may
be similar to your train of thought. You should also read the [updated
paper|http://arxiv.org/pdf/1512.00727.pdf] which goes into much more depth.
> 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)
