hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-19357) Bucket cache no longer L2 for LRU cache
Date Wed, 29 Nov 2017 05:04:01 GMT

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

Anoop Sam John commented on HBASE-19357:

Why the second cache name came is - It might not be BucketCache always. We have the external
cache also.  Ya that external cache is L2 for LRU cache any way.  If it is not that much confusing
ya for name we can keep it as L1 and L2 only as of now?
bq.I can configure the seond cache to be on heap too, IIRC? 
No. Already removed that support
bq.You want to deprecate HCD# setCacheDataInL1 ? Or you figure no need because whole class
is deprecated?
Ya as class is fully deprecated I did not add. I can add deprecation there too in next patch
bq.We still need a victim handler?
I feel not needed. The index blocks only go to L1 now. If there is no space let eviction happen.
Any way eviction is needed there as we will have compaction and some old reads which are no
longer active now.. Let them be evicted out rather than to L2 disturbing the data cache part.
 Any way that will give a better idea for admin from the UI whether the evictions are more
in L1 or not. If more, may be they should increase the L1 size.  We are moving the max of
the heap size requirements out of heap now.  

> Bucket cache no longer L2 for LRU cache
> ---------------------------------------
>                 Key: HBASE-19357
>                 URL: https://issues.apache.org/jira/browse/HBASE-19357
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>             Fix For: 2.0.0-beta-1
>         Attachments: HBASE-19357.patch, HBASE-19357.patch
> When Bucket cache is used, by default we dont configure it as an L2 cache alone. The
default setting is combined mode ON where the data blocks to Bucket cache and index/bloom
blocks go to LRU cache. But there is a way to turn this off and make LRU as L1 and Bucket
cache as a victim handler for L1. It will be just L2.   
> After the off heap read path optimization Bucket cache is no longer slower compared to
L1. We have test results on data sizes from 12 GB.  The Alibaba use case was also with 12
GB and they have observed a ~30% QPS improve over the LRU cache.
> This issue is to remove the option for combined mode = false. So when Bucket cache is
in use, data blocks will go to it only and LRU will get only index /meta/bloom blocks.   Bucket
cache will no longer be configured as a victim handler for LRU.
> Note : WHen external cache is in use, there only the L1 L2 thing comes. LRU will be L1
and external cache act as its L2. That make full sense.

This message was sent by Atlassian JIRA

View raw message