[
https://issues.apache.org/jira/browse/KUDU-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873739#comment-17873739
]
ASF subversion and git services commented on KUDU-613:
------------------------------------------------------
Commit b8b080651e528080b8b4b5b58c6f1021b2dd01da in kudu's branch
refs/heads/master from Mahesh Reddy
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=b8b080651 ]
KUDU-613: SLRU Cache Benchmark
This patch introduces a new benchmark that
validates the performance of the SLRU cache.
The pattern this benchmark follows is frequent lookups
for a small set of keys followed by lookups for rarely
accessed keys with large values that would normally
evict the frequently accessed keys from the LRU
cache. As the results below show, SLRU cache
performs better with this workload pattern.
Ran benchmarks for RELEASE build locally on macOS.
6 cores and 2.6GHz.
Results:
Test case | Algorithm | Lookups/sec | Hit rate
ZIPFIAN ratio=1.00x | LRU | 11.43M | 99.8%
ZIPFIAN ratio=1.00x | SLRU | 10.68M | 98.6%
ZIPFIAN ratio=3.00x | LRU | 11.43M | 95.8%
ZIPFIAN ratio=3.00x | SLRU | 10.07M | 93.4%
UNIFORM ratio=1.00x | LRU | 9.31M | 99.7%
UNIFORM ratio=1.00x | SLRU | 7.51M | 99.7%
UNIFORM ratio=3.00x | LRU | 6.80M | 33.3%
UNIFORM ratio=3.00x | SLRU | 5.09M | 11.0%
PRE_DETERMINED ratio=1.00x | LRU | 17.73M | 93.1%
PRE_DETERMINED ratio=1.00x | SLRU | 18.58M | 99.2%
PRE_DETERMINED ratio=3.00x | LRU | 17.07M | 93.1%
PRE_DETERMINED ratio=3.00x | SLRU | 19.12M | 99.1%
Change-Id: I1c128a9f047497373ce3e740056eaa89a352261b
Reviewed-on: http://gerrit.cloudera.org:8080/21601
Reviewed-by: Alexey Serbin <ale...@apache.org>
Tested-by: Alexey Serbin <ale...@apache.org>
> Scan-resistant cache replacement algorithm for the block cache
> --------------------------------------------------------------
>
> Key: KUDU-613
> URL: https://issues.apache.org/jira/browse/KUDU-613
> Project: Kudu
> Issue Type: Improvement
> Components: perf
> Affects Versions: M4.5
> Reporter: Andrew Wang
> Assignee: Mahesh Reddy
> Priority: Major
> Labels: performance, roadmap-candidate
>
> The block cache currently uses LRU, which is vulnerable to large scan
> workloads. It'd be good to implement something like 2Q.
> ARC (patent encumbered, but good for ideas):
> https://www.usenix.org/conference/fast-03/arc-self-tuning-low-overhead-replacement-cache
> HBase (2Q like):
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
