[
https://issues.apache.org/jira/browse/HBASE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103828#comment-13103828
]
Ted Yu commented on HBASE-4380:
-------------------------------
Can we utilize the following ?
http://download.oracle.com/javase/1.5.0/docs/guide/management/mxbeans.html#low_memory
http://download.oracle.com/javase/1.5.0/docs/api/java/lang/management/MemoryPoolMXBean.html
> 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
