Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <313255568.1247776394904.JavaMail.jira@brutus>
Date: Thu, 16 Jul 2009 13:33:14 -0700 (PDT)
From: "stack (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Reopened: (HBASE-1058) Prevent runaway compactions
In-Reply-To: <1114482934.1229119364146.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack reopened HBASE-1058:
--------------------------


We took this patch out of 0.19 but its still in TRUNK.  Reopening to remove this patch from TRUNK.

What I just saw was on start up of a >1k region cluster, .META. was getting lots of edits as regions were coming on line so it was flushing, flushing, flushing (because we flush region when it hits 32k), but quickly, we got into a state where meta would not flush because too many file on fileystem and we were waiting for the compaction to complete (90seconds).  During this time .META. was taking on no edits because the .META. memstore was > its 32k limit.  Cluster was not opening up regions.

> Prevent runaway compactions
> ---------------------------
>
>                 Key: HBASE-1058
>                 URL: https://issues.apache.org/jira/browse/HBASE-1058
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
>            Assignee: Andrew Purtell
>            Priority: Blocker
>         Attachments: hbase-1058-2-v1.patch, hbase-1058-v2.patch, hbase-1058-v4.patch, hbase-1058.patch
>
>
> A rabid upload will easily outrun our compaction ability dropping flushes faster than we can compact them up.  Fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.