cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Manes (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11452) Cache implementation using LIRS eviction for in-process page cache
Date Tue, 12 Apr 2016 23:58:25 GMT


Ben Manes commented on CASSANDRA-11452:

For the case of 128mb cache with 190mb data set, the degredation may be due to Caffeine's
lazily initialization of the sketch. This is done when cache is at least 50% full to avoid
penalizing by setting an artificially high bound. This change was suggested on the other Cassandra
ticket to also avoid the unnecessary penalty when the cache exceeds the data size, e.g. due
to expiration and a safety threshold that is never reachable.

For maximum weight the expected number of entries is unknown. This probably causes it to resize
more frequently in order to keep the sketch's error rate constant, causing it to lose the
history. When the cache is full the entry count won't differ all that much, so it begins to
capture the frequency histogram but the trace ends before its made up for the poor start.
This might be why the smaller sizes did well and the larger ones suffered.

In the latest SNAPSHOT the {{initialCapacity}} setting will pre-size the sketch in addition
to the hash table ([commit|]).
Then if you know the average entry size this problem won't occur.

> Cache implementation using LIRS eviction for in-process page cache
> ------------------------------------------------------------------
>                 Key: CASSANDRA-11452
>                 URL:
>             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

View raw message