[
https://issues.apache.org/jira/browse/HBASE-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307647#comment-14307647
]
Lars Hofhansl commented on HBASE-12976:
---------------------------------------
Actually, with this in place, we can up the default scanner caching to
Long.MAX_VALUE. It'll be capped at 2mb.
The only reason to set scanner caching now is when the client knows how many
rows it is going to need or expect.
So scanner caching is now only used to *limit* the result size based on
semantic knowledge of the client, but no longer to optimize the batch sizes.
Might even rename caching to rowLimit or something.
There might be effects with coprocessors that I would need to double check, so
I won't do that part in this jira.
> Default hbase.client.scanner.max.result.size
> --------------------------------------------
>
> Key: HBASE-12976
> URL: https://issues.apache.org/jira/browse/HBASE-12976
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Fix For: 2.0.0, 1.0.1, 0.94.27, 0.98.11
>
> Attachments: 12976.txt
>
>
> Setting scanner caching is somewhat of a black art. It's hard to estimate
> ahead of time how large the result set will be.
> I propose we hbase.client.scanner.max.result.size to 2mb. That is good
> compromise between performance and buffer usage on typical networks (avoiding
> OOMs when the caching was chosen too high).
> To an HTable client this is completely transparent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
