[
https://issues.apache.org/jira/browse/HBASE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103478#comment-13103478
]
Ted Yu commented on HBASE-4380:
-------------------------------
@Ming:
There is a config parameter: hbase.client.scanner.max.result.size whose default
is Long.MAX_VALUE
Take a look at line 2063 in HRegionServer:
{code}
for (int i = 0; i < nbRows
&& currentScanResultSize < maxScannerResultSize; i++) {
requestCount.incrementAndGet();
{code}
> 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
