[
https://issues.apache.org/jira/browse/HBASE-26681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yutong Xiao updated HBASE-26681:
--------------------------------
Description:
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!
Client Side Metrics
See the attachment ClientSideMetrics.png
was:
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!
Client Side Metrics
!ClientSideMetrics.png|height=300|width=300!
> 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!
> Client Side Metrics
> See the attachment ClientSideMetrics.png
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
