[
https://issues.apache.org/jira/browse/HBASE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans updated HBASE-2056:
--------------------------------------
Fix Version/s: (was: 0.20.3)
0.20.4
Will not be part of 0.20.3
> Wiser configurations
> --------------------
>
> Key: HBASE-2056
> URL: https://issues.apache.org/jira/browse/HBASE-2056
> Project: Hadoop HBase
> Issue Type: Improvement
> Affects Versions: 0.20.2
> Reporter: Jean-Daniel Cryans
> Fix For: 0.20.4, 0.21.0
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
