[jira] [Commented] (HBASE-26681) Introduce a little RAMBuffer for bucketcache to reduce gc and improve throughput

["Hudson (Jira)" <ji...@apache.org>]

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

Hudson commented on HBASE-26681:
--------------------------------

Results for branch branch-1
	[build #229 on builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-1/229/]: (x) *{color:red}-1 overall{color}*
----
details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-1/229//General_Nightly_Build_Report/]


(/) {color:green}+1 jdk7 checks{color}
-- For more information [see jdk7 report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-1/229//JDK7_Nightly_Build_Report/]


(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-1/229//JDK8_Nightly_Build_Report_(Hadoop2)/]




(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Introduce a little RAMBuffer for bucketcache to reduce gc and improve throughput
> --------------------------------------------------------------------------------
>
>                 Key: HBASE-26681
>                 URL: https://issues.apache.org/jira/browse/HBASE-26681
>             Project: HBase
>          Issue Type: Improvement
>          Components: BucketCache, Performance
>            Reporter: Yutong Xiao
>            Assignee: Yutong Xiao
>            Priority: Major
>             Fix For: 1.7.2
>
>         Attachments: ClientSideMetrics.png, Hit 100%.png, Properties.png
>
>
> In branch-1, BucketCache just allocate new onheap bytebuffer to construct new HFileBlock when get cached blocks. This rough allocation increases the GC pressure for those "hot" blocks. 
> Here introduce a RAMBuffer for those "hot" blocks in BucketCache. The thought is simple. The RAMBuffer is an timeout expiring cache. When a Multi-level block is read twice, we cache it in the RAMBuffer. When the block timeout in the cache (e.g. 60s), that means the block is not being accessed in 60s, we evict it. Not like LRU, we do not cache block when the whole RAMBuffer size reaches to a threshold (to fit different workload, the threshold is dynamic). This will prevent the RAMBuffer from being churned.
> {panel:title=The performance of RAMBuffer with its hit ratio is 100%}
> !Hit 100%.png|height=250|width=250!
> {panel}
> I also did a YCSB performance test. 
> The circumstance is:
> Size of BucketCache: 40 GB
> Target table size: 112 GB
> Properties:
> !Properties.png|height=250|width=250!
> The operation distribution of YCSB workload is latest.
> Client Side Metrics
> See the attachment ClientSideMetrics.png
> Server Side GC:
> The current bucket cache triggered 217 GCs, which costs 2.74 minutes in total.
> With RAMBuffer, the server side had 210 times GC and 2.56 minutes in total.
> As the master & branch-2 using ByteBufferAllocator to manage the bucketcache memory allocation, the RAMBuffer may not have GC improvement as much as branch-1. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)