Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 27 May 2011 14:42:47 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <2015040487.48804.1306507367433.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <22132091.170001294263285209.JavaMail.jira@thor>
Subject: [jira] [Commented] (HBASE-3421) Very wide rows -- 30M plus -- cause
 us OOME
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040260#comment-13040260 ] 

stack commented on HBASE-3421:
------------------------------

bq. Anyone foresee an issue with just using a limit of 10 KVs on the scan(kvs) call in the compaction loop?

No. Things might run imperceptibly slower.

> Very wide rows -- 30M plus -- cause us OOME
> -------------------------------------------
>
>                 Key: HBASE-3421
>                 URL: https://issues.apache.org/jira/browse/HBASE-3421
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.90.0
>            Reporter: stack
>
> From the list, see 'jvm oom' in http://mail-archives.apache.org/mod_mbox/hbase-user/201101.mbox/browser, it looks like wide rows -- 30M or so -- causes OOME during compaction.  We should check it out. Can the scanner used during compactions use the 'limit' when nexting?  If so, this should save our OOME'ing (or, we need to add to the next a max size rather than count of KVs).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira