[
https://issues.apache.org/jira/browse/HBASE-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673331#comment-13673331
]
Jean-Daniel Cryans commented on HBASE-8635:
-------------------------------------------
bq. Fortunately, this is for 0.96. I agree it is a concern, but it will be a
little less of concern.
I can already see the emails titled "Upgraded to 0.96.0 but cluster doesn't
start, help!" in which we tell them they have to change their configs and they
have to pick which one of the 3 they want less of.
bq. I think it is good to scale with the amount of memory given to HBase
I thought I gave a good demonstration why this is not a good idea with bigger
heaps, was there anything you didn't agree with or do you have a
counter-example?
bq. Prefetching, however, should help all the time
Well, Get-based workloads won't be faster and short Scans that require only 1
next call won't either. Short Scans that require a few next calls will
beneficiate from it but I don't see that sort of use case needing GBs of
prefetching.
> Define prefetcher.resultsize.max as percentage
> ----------------------------------------------
>
> Key: HBASE-8635
> URL: https://issues.apache.org/jira/browse/HBASE-8635
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
> Assignee: Jimmy Xiang
> Priority: Minor
> Attachments: trunk-8635.patch
>
>
> Currently "hbase.hregionserver.prefetcher.resultsize.max" defines global
> limit for prefetching.
> The default value is 256MB.
> It would be more flexible to define this measure as a percentage of the heap.
--
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
