[
https://issues.apache.org/jira/browse/HBASE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103818#comment-13103818
]
Ming Ma commented on HBASE-4380:
--------------------------------
Thanks, Ted. That should work for a more controlled environment like predefined
hbase map job where we know the max number of concurrent scans at a given time
for a given RS. In the case where any numbers of clients can call at any given
time, we will need a better solution.
> large scan caching size causes RS to throw OOME
> -----------------------------------------------
>
> Key: HBASE-4380
> URL: https://issues.apache.org/jira/browse/HBASE-4380
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Ming Ma
> Assignee: Ming Ma
>
> If the hbase application specifies a large caching size via
> Scan.setCaching(...), RS will try to accumulate enough rows before returning
> to the client. This could blow up RS memory. In TableInputFormat scenario, we
> have couple mappers with large caching size, thus RS memory usage goes up
> quickly.
> RS perhaps should take memory usage into account, for example, return less
> results per HRegionInterface.next(long scannerId, int numberOfRows) call in
> the case of low memory.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
