[
https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057359#comment-15057359
]
ramkrishna.s.vasudevan commented on HBASE-14978:
------------------------------------------------
{code}
if (c.getRowArray() != lastBlock) {
1084 lastBlock = c.getRowArray();
1085 context.incrementResponseBlockSize(lastBlock.length);
1086 }
{code}
I think your calculation makes sense reg the number of blocks being referenced
till the results of the gets are sent out.
For the offheap case may be this will not happen- but one thing with the above
code even in offheap case we may only have BB backing the Result Cells and that
time doing c.getRowArray may do a copy every time and this would always
increase the last blcok count. Let me see once again.
> Don't allow Multi to retain too many blocks
> -------------------------------------------
>
> Key: HBASE-14978
> URL: https://issues.apache.org/jira/browse/HBASE-14978
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 2.0.0, 1.2.0, 1.3.0
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Priority: Critical
> Attachments: HBASE-14978.patch
>
>
> Scans and Multi's have limits on the total size of cells that can be
> returned. However if those requests are not all pointing at the same blocks
> then the KeyValues can keep alive a lot more data than their size.
> Take the following example:
> A multi with a list of 10000 gets to a fat row. Each column being returned in
> in a different block. Each column is small 32 bytes or so.
> So the total cell size will be 32 * 10000 = ~320kb. However if each block is
> 128k then total retained heap size will be almost 2gigs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
