[
https://issues.apache.org/jira/browse/KUDU-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904643#comment-17904643
]
ASF subversion and git services commented on KUDU-613:
------------------------------------------------------
Commit 33fd5e482b4854d23247af903c4263afc9931e59 in kudu's branch
refs/heads/master from Mahesh Reddy
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=33fd5e482 ]
KUDU-613: Remove use of vectors under lock
Currently, the implementation of the SLRU cache returns
a vector of temporarily evicted entries to be reinserted
later. There are performance concerns with this approach
as it allocates and deallocates memory under the lock.
This patch refactors the code to not use a vector to deal
with the temporarily evicted entries.
Change-Id: I8f6a019c7c033c6c3dfef59b0f037e78f8264e68
Reviewed-on: http://gerrit.cloudera.org:8080/22181
Tested-by: Alexey Serbin <ale...@apache.org>
Reviewed-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)
