[
https://issues.apache.org/jira/browse/HBASE-20059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16427151#comment-16427151
]
stack commented on HBASE-20059:
-------------------------------
Looks great. A few notes:
bq. 2 This feature is available from HBase 2.0.0. We recomend users to switch
to off heap Bucket Cache as it will make the RegionServer to work with much
lower heap size.
Above recommendation is premature? We need to do some testing first beyond what
you fellows have done? Long burn ins? Couch it some?
Make these into asciidoc links: 685
https://blogs.apache.org/hbase/entry/offheaping_the_read_path_in
686 https://blogs.apache.org/hbase/entry/offheap-read-path-in-production
bq. 691 Please note that we have removed the notion of L1 and L2 here.
There is no movement of blocks from LruBlockCache to BucketCache or vice versa.
This is the 'victim' stuff described earlier? If so, use the term 'victim' to
tie it to previous description.
We seem to repeat this a few times:
the data blocks will always go to BucketCache and index, bloom blocks go to on
heap LRUBlockCache. `cacheDataInL1` support is also removed.
Should we do an edit to strip notions of L1 and L2 from the refguide?
Where is config on enabling offheap read-path and then offheap write-path? How
does operator know it enabled? Any metrics or logs the operator should be
looking for to see that configs have taken or effectiveness of offheaping?
Better review after looking at the patch in context. Thanks A.
> Make sure documentation is updated for the offheap Bucket cache usage
> ---------------------------------------------------------------------
>
> Key: HBASE-20059
> URL: https://issues.apache.org/jira/browse/HBASE-20059
> Project: HBase
> Issue Type: Sub-task
> Components: documentation
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20059.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
