You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2009/09/03 07:28:32 UTC

[jira] Created: (HBASE-1813) Remove compaction governor

Remove compaction governor
--------------------------

                 Key: HBASE-1813
                 URL: https://issues.apache.org/jira/browse/HBASE-1813
             Project: Hadoop HBase
          Issue Type: Bug
            Reporter: stack
             Fix For: 0.21.0


It might make sense now undoing the compaction governor:

>From the list (read in reverse):

{code}
Andrew Purtell
 to hbase-user
	
show details 10:18 PM (7 minutes ago)
	
I had a similar thought, that this could be removed in 0.21.

  - Andy




________________________________
From: stack <st...@duboce.net>
To: hbase-user@hadoop.apache.org
Sent: Wednesday, September 2, 2009 8:13:06 PM
Subject: Re: Compactions no longer limited

Andrew:

Maybe now that in 0.20.0 we only run compaction on open IFF the region has
references, may be this facility is no longer needed?

St.Ack

On Wed, Sep 2, 2009 at 6:05 PM, Andrew Purtell <ap...@apache.org> wrote:

> Hi Ken,
>
> Compactions are serviced by a thread which sleeps for a configurable
> interval and then wakes to do work. As compaction requests are raised, they
> are queued and the thread is signaled and wakes early. When a region server
> first starts up, a limit is imposed on how many compaction requests can be
> serviced from the queue before the thread goes back to sleep. The limit is
> gradually relaxed. The net effect is to draw out compactions over an initial
> "safe mode". The reason this is done is to limit load on DFS when the
> cluster is starting. Compactions during this period often process flushes
> from the last shutdown and can well trigger splits. Around the 0.19
> timeframe I had a 25 node test cluster pushing 1000 regions per node.
> Startup compaction/split activity would crush DFS and prevent successful
> (re)starts. The mechanism described here solved that issue.
>
>    - Andy
{code}

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


[jira] Resolved: (HBASE-1813) Remove compaction governor

Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Purtell resolved HBASE-1813.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.20.3

Resolved by other issues.

> Remove compaction governor
> --------------------------
>
>                 Key: HBASE-1813
>                 URL: https://issues.apache.org/jira/browse/HBASE-1813
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
>             Fix For: 0.20.3, 0.21.0
>
>
> It might make sense now undoing the compaction governor:
> From the list (read in reverse):
> {code}
> Andrew Purtell
>  to hbase-user
> 	
> show details 10:18 PM (7 minutes ago)
> 	
> I had a similar thought, that this could be removed in 0.21.
>   - Andy
> ________________________________
> From: stack <st...@duboce.net>
> To: hbase-user@hadoop.apache.org
> Sent: Wednesday, September 2, 2009 8:13:06 PM
> Subject: Re: Compactions no longer limited
> Andrew:
> Maybe now that in 0.20.0 we only run compaction on open IFF the region has
> references, may be this facility is no longer needed?
> St.Ack
> On Wed, Sep 2, 2009 at 6:05 PM, Andrew Purtell <ap...@apache.org> wrote:
> > Hi Ken,
> >
> > Compactions are serviced by a thread which sleeps for a configurable
> > interval and then wakes to do work. As compaction requests are raised, they
> > are queued and the thread is signaled and wakes early. When a region server
> > first starts up, a limit is imposed on how many compaction requests can be
> > serviced from the queue before the thread goes back to sleep. The limit is
> > gradually relaxed. The net effect is to draw out compactions over an initial
> > "safe mode". The reason this is done is to limit load on DFS when the
> > cluster is starting. Compactions during this period often process flushes
> > from the last shutdown and can well trigger splits. Around the 0.19
> > timeframe I had a 25 node test cluster pushing 1000 regions per node.
> > Startup compaction/split activity would crush DFS and prevent successful
> > (re)starts. The mechanism described here solved that issue.
> >
> >    - Andy
> {code}

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