hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15513) hbase.hregion.memstore.chunkpool.maxsize is 0.0 by default
Date Tue, 22 Mar 2016 16:23:25 GMT

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

stack commented on HBASE-15513:

bq. Stack Can you explain how not reusing buffers can improve performance and latency? I am
just trying to understand magic physics of "allocate buffer on every request" approach.

See where Elliott wanted a flag to disable pooled bytebuffers because it put a spanner in
his G1GC works; HBASE-14942. On the face of it 'reuse' should be always better but the Elliott
issue and a new one coming in that [~ram_krish] and [~anoop.hbase] are studying a case where
resuse seems to make for less GC but the GC runs for longer, would seem to indicate that 'reuse'
is not panacea. My suggestion is we do some basic testing to verify no side effects..... Do
it now as part of check-in rather than let some poor sod down the line figure there an unexpected
regression (and have to figure it without context). See the original issue too where there
is discussion on when to enable the pool.

> hbase.hregion.memstore.chunkpool.maxsize is 0.0 by default
> ----------------------------------------------------------
>                 Key: HBASE-15513
>                 URL: https://issues.apache.org/jira/browse/HBASE-15513
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 2.0.0
>            Reporter: Vladimir Rodionov
>            Assignee: Vladimir Rodionov
>             Fix For: 2.0.0
> That results in excessive MemStoreLAB chunk allocations because we can not reuse them.
Not sure, why it has been disabled, by default. May be the code has not been tested well?

This message was sent by Atlassian JIRA

View raw message