[
https://issues.apache.org/jira/browse/HBASE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans resolved HBASE-2056.
---------------------------------------
Resolution: Duplicate
Kind of invalid since so old, kind of a duplicate of HBASE-8450.
> Wiser configurations
> --------------------
>
> Key: HBASE-2056
> URL: https://issues.apache.org/jira/browse/HBASE-2056
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.20.2
> Reporter: Jean-Daniel Cryans
> Priority: Minor
> Labels: moved_from_0_20_5
>
> Some of our default configurations do badly on machines that are provided
> with more CPUs and RAM. For example:
> hbase.regionserver.global.memstore.upperLimit=0.4
> hbase.regionserver.global.memstore.lowerLimit=0.25
> That's good if you have 1GB heap, you just flush 250MB. On a 4GB heap,
> upper=1.6 and lower=.9 so you have to flush 700MB which is blocking a lot. In
> this case you could use a lot more than 40% of available heap and the lower
> limit should still be something like 250MB.
> hbase.master.meta.thread.rescanfrequency should adapt itself to the number of
> rows, small clusters would boot faster by default and bigger clusters would
> scan it using the current value (1 min).
> hbase.regionserver.lease.period should adapt itself if clients are always
> reporting after some seconds. For example if it often reports after 30-40
> seconds then we should temporarily set the default higher than 60 seconds. An
> average on some sampling could help.
> hbase.regions.percheckin set it higher if average load will be big? Like on
> the first scan on .META., you take the number of RS and check the average
> load to set this value.
> hbase.hstore.blockingStoreFiles higher if more heap available when we boot?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
