hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (HBASE-1058) Prevent runaway compactions
Date Thu, 16 Jul 2009 20:33:14 GMT

     [ 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.


Mime
View raw message