hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Manes (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-15560) TinyLFU-based BlockCache
Date Thu, 13 Oct 2016 08:38:20 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571276#comment-15571276
] 

Ben Manes edited comment on HBASE-15560 at 10/13/16 8:37 AM:
-------------------------------------------------------------

The update latencies, except for average, were very similar. Since presumably not all entries
fit in the cache then an update of a miss would trigger an eviction. It could be impact from
the O(n lg n) Lru eviction thread, GC, or more coarse grained locking. Since this was run
on a macbook rather than an isolated server, it could also be a background daemon kicking
in. I think the important take away is not the absolute but that they are in the same ballpark.
There isn't an outlier indicating the new implementation has a major degredation, e.g. due
to locking or hit rates.

[~eshcar]: To more directly answer your question, the update cost is [very close|https://github.com/ben-manes/caffeine/wiki/Benchmarks#write-100-1]
to ConcurrentHashMap. This is because the locking overhead dominates, leaving enough spare
cpu cycles to mask any other penalties being processed asynchronously.

[~anoopsamjohn] In my original post the results mentioned were probably with no evictions.
Because LruBlockCache penalizes only the eviction, whereas Caffeine spreads it out, one would
expect Lru to have an advantage. But by Amdahl's law the potential speedup is very tiny, so
it falls into the noise. A fresh test would be good.


was (Author: ben.manes):
The update latencies, except for average, were very similar. Since presumably not all entries
fit in the cache then an update of a miss would trigger an eviction. It could be impact from
the O(n lg n) Lru eviction thread, GC, or more coarse grained locking. Since this was run
on a macbook rather than an isolated server, it could also be a background daemon kicking
in. I think the important take away is not the absolute but that they are in the same ballpark.
There isn't an outlier indicating the new implementation has a major degredation, e.g. due
to locking or hit rates.

[~eshcar]: To more directly answer your question, the update cost is [very close|https://github.com/ben-manes/caffeine/wiki/Benchmarks#write-100-1]
to ConcurrentHashMap. This is because the locking overhead dominates, leaving enough spare
cpu cycles to mask any other penalties being processed asynchronously.

[~anoopamz] In my original post the results mentioned were probably with no evictions. Because
LruBlockCache penalizes only the eviction, whereas Caffeine spreads it out, one would expect
Lru to have an advantage. But by Amdahl's law the potential speedup is very tiny, so it falls
into the noise. A fresh test would be good.

> TinyLFU-based BlockCache
> ------------------------
>
>                 Key: HBASE-15560
>                 URL: https://issues.apache.org/jira/browse/HBASE-15560
>             Project: HBase
>          Issue Type: Improvement
>          Components: BlockCache
>    Affects Versions: 2.0.0
>            Reporter: Ben Manes
>            Assignee: Ben Manes
>         Attachments: HBASE-15560.patch, HBASE-15560.patch, HBASE-15560.patch, HBASE-15560.patch,
HBASE-15560.patch, HBASE-15560.patch, HBASE-15560.patch, tinylfu.patch
>
>
> LruBlockCache uses the Segmented LRU (SLRU) policy to capture frequency and recency of
the working set. It achieves concurrency by using an O( n ) background thread to prioritize
the entries and evict. Accessing an entry is O(1) by a hash table lookup, recording its logical
access time, and setting a frequency flag. A write is performed in O(1) time by updating the
hash table and triggering an async eviction thread. This provides ideal concurrency and minimizes
the latencies by penalizing the thread instead of the caller. However the policy does not
age the frequencies and may not be resilient to various workload patterns.
> W-TinyLFU ([research paper|http://arxiv.org/pdf/1512.00727.pdf]) records the frequency
in a counting sketch, ages periodically by halving the counters, and orders entries by SLRU.
An entry is discarded by comparing the frequency of the new arrival (candidate) to the SLRU's
victim, and keeping the one with the highest frequency. This allows the operations to be performed
in O(1) time and, though the use of a compact sketch, a much larger history is retained beyond
the current working set. In a variety of real world traces the policy had [near optimal hit
rates|https://github.com/ben-manes/caffeine/wiki/Efficiency].
> Concurrency is achieved by buffering and replaying the operations, similar to a write-ahead
log. A read is recorded into a striped ring buffer and writes to a queue. The operations are
applied in batches under a try-lock by an asynchronous thread, thereby track the usage pattern
without incurring high latencies ([benchmarks|https://github.com/ben-manes/caffeine/wiki/Benchmarks#server-class]).
> In YCSB benchmarks the results were inconclusive. For a large cache (99% hit rates) the
two caches have near identical throughput and latencies with LruBlockCache narrowly winning.
At medium and small caches, TinyLFU had a 1-4% hit rate improvement and therefore lower latencies.
The lack luster result is because a synthetic Zipfian distribution is used, which SLRU performs
optimally. In a more varied, real-world workload we'd expect to see improvements by being
able to make smarter predictions.
> The provided patch implements BlockCache using the [Caffeine|https://github.com/ben-manes/caffeine]
caching library (see HighScalability [article|http://highscalability.com/blog/2016/1/25/design-of-a-modern-cache.html]).
> Edward Bortnikov and Eshcar Hillel have graciously provided guidance for evaluating this
patch ([github branch|https://github.com/ben-manes/hbase/tree/tinylfu]).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message