hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11209) Increase the default value for hbase.hregion.memstore.block.multipler from 2 to 4
Date Sun, 25 May 2014 22:50:02 GMT

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

Hudson commented on HBASE-11209:
--------------------------------

SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #295 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/295/])
HBASE-11209 Increase the default value for hbase.hregion.memstore.block.multipler from 2 to
4 (nkeywal: rev 5521dfe6f05c8f49f2ebfa1c54b80169f2296a83)
* hbase-common/src/main/resources/hbase-default.xml


> Increase the default value for hbase.hregion.memstore.block.multipler from 2 to 4
> ---------------------------------------------------------------------------------
>
>                 Key: HBASE-11209
>                 URL: https://issues.apache.org/jira/browse/HBASE-11209
>             Project: HBase
>          Issue Type: Brainstorming
>          Components: regionserver
>    Affects Versions: 0.99.0, 0.98.2
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>             Fix For: 0.99.0, 0.98.3
>
>         Attachments: HBASE-11209.patch
>
>
> On a YCSB test, I saw a 33% performance increase, both on the max latency and on the
throughput. I'm convinced enough that this value is better that I think it makes sense to
change it on 0.98 as well.
> More fundamentally, but outside of the scope of this patch, I think this parameter should
be changed to something at the region server level: today, we have:
> - global memstore check: if we're other 40%, we flush the biggest memstore
> - local: no more than 2 (proposed: 4) memstore size per region.
> But if we have enough memory and a spike on a region, there is no reason for not taking
the write.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message