[
https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057628#comment-15057628
]
ramkrishna.s.vasudevan commented on HBASE-14978:
------------------------------------------------
bqThe check is still on getRowArray()
I see. I missed that.
bq.In fact with off heap Cell, which are delivered from L2 off heap cache, we
wont get any OOME issue whatever be the #blocks one request touches. We avoid
copying of block data from L2 off heap space to temp byte[]. So these Cells
refer to the L2 cache space only.
Yes. I too think so.. See my above comment 'For the offheap case may be this
will not happen- '.
> 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-v1.patch, 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)
