[
https://issues.apache.org/jira/browse/CASSANDRA-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15240789#comment-15240789
]
Branimir Lambov commented on CASSANDRA-11452:
---------------------------------------------
bq. For this to be a problem it would have to be a collision on all
hashes/buckets, ...
I don't consider this a real problem for page caches, but more generally the
initial hash is an int, and in a 24/7, 50k ops/sec operation I wouldn't rely on
not getting _any_ clashes. They will be very rare, granted, but should the
scenario below realize, it would be quite a serious problem.
bq. Bear in mind also that - as opposed to LIRS which is an eviction strategy -
LFU only prevents promotion to the LRU; the eviction strategy is still LRU, so
it will not keep collisions, only fail to filter them before they hit the
(main) cache.
This makes things even worse. Looking at the {{BoundedLocalCache}} code in
detail, I can see that if a collision is to filter down to the head of the
probation space queue, it will always be the eviction victim and (presuming the
colliding entry remains hot) would thus win over every candidate coming from
the eden space, at least in theory. As a result the cache is reduced to just
the eden window, 1% of the space and plain LRU eviction. This _can_ happen in
Caffeine, take a look at [this test|http://pastebin.com/dmxK9bFv].
There appears to be an easy fix, though. Changing the {{candidateFreq >
victimFreq}} comparison in {{evictFromMain}} to non-strict to prefer the
candidate on equality makes such stuck victims much easier to eject as the
range of the counters is small and should be easily reachable for a hot
candidate. [~ben.manes], is there a reason for the strictness of this
comparison (the paper is very elusive on these choices)?
> 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)
