You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-user@hadoop.apache.org by Manish Katyal <ma...@gmail.com> on 2009/05/13 18:48:09 UTC

Regarding Capacity Scheduler

I'm experimenting with the Capacity scheduler (0.19.0) in a multi-cluster
environment.
I noticed that unlike the mappers, the reducers are not pre-empted?

I have two queues (high and low) that are each running big jobs (70+ maps
each).  The scheduler splits the mappers as per the queue
guaranteed-capacity (5/8ths for the high and the rest for the low). However,
the reduce jobs are not interleaved -- the reduce job in the high queue is
blocked waiting for the reduce job in the low queue to complete.

Is this a bug or by design?

*Low queue:*
Guaranteed Capacity (%) : 37.5
Guaranteed Capacity Maps : 3
Guaranteed Capacity Reduces : *3*
User Limit : 100
Reclaim Time limit : 300
Number of Running Maps : 3
Number of Running Reduces : *7*
Number of Waiting Maps : 131
Number of Waiting Reduces : 0
Priority Supported : NO

*High queue:*
Guaranteed Capacity (%) : 62.5
Guaranteed Capacity Maps : 5
Guaranteed Capacity Reduces : 5
User Limit : 100
Reclaim Time limit : 300
Number of Running Maps : 4
Number of Running Reduces : *0*
Number of Waiting Maps : 68
Number of Waiting Reduces : *7*
Priority Supported : NO

Re: Regarding Capacity Scheduler

Posted by Hemanth Yamijala <yh...@yahoo-inc.com>.
Manish,

The pre-emption code in capacity scheduler was found to require a good 
relook and due to the inherent complexity of the problem is likely to 
have issues of the type you have noticed. We have decided to relook at 
the pre-emption code from scratch and to this effect removed it from the 
0.20 branch to start afresh.

Thanks
Hemanth

Manish Katyal wrote:
> I'm experimenting with the Capacity scheduler (0.19.0) in a multi-cluster
> environment.
> I noticed that unlike the mappers, the reducers are not pre-empted?
>
> I have two queues (high and low) that are each running big jobs (70+ maps
> each).  The scheduler splits the mappers as per the queue
> guaranteed-capacity (5/8ths for the high and the rest for the low). However,
> the reduce jobs are not interleaved -- the reduce job in the high queue is
> blocked waiting for the reduce job in the low queue to complete.
>
> Is this a bug or by design?
>
> *Low queue:*
> Guaranteed Capacity (%) : 37.5
> Guaranteed Capacity Maps : 3
> Guaranteed Capacity Reduces : *3*
> User Limit : 100
> Reclaim Time limit : 300
> Number of Running Maps : 3
> Number of Running Reduces : *7*
> Number of Waiting Maps : 131
> Number of Waiting Reduces : 0
> Priority Supported : NO
>
> *High queue:*
> Guaranteed Capacity (%) : 62.5
> Guaranteed Capacity Maps : 5
> Guaranteed Capacity Reduces : 5
> User Limit : 100
> Reclaim Time limit : 300
> Number of Running Maps : 4
> Number of Running Reduces : *0*
> Number of Waiting Maps : 68
> Number of Waiting Reduces : *7*
> Priority Supported : NO
>
>   


Re: Regarding Capacity Scheduler

Posted by Billy Pearson <bi...@sbcglobal.net>.

I am seeing the the same problem posted on the list on the 11th and have not 
any reply.

Billy


----- Original Message ----- 
From: "Manish Katyal" 
<ma...@public.gmane.org>
Newsgroups: gmane.comp.jakarta.lucene.hadoop.user
To: <co...@public.gmane.org>
Sent: Wednesday, May 13, 2009 11:48 AM
Subject: Regarding Capacity Scheduler


> I'm experimenting with the Capacity scheduler (0.19.0) in a multi-cluster
> environment.
> I noticed that unlike the mappers, the reducers are not pre-empted?
>
> I have two queues (high and low) that are each running big jobs (70+ maps
> each).  The scheduler splits the mappers as per the queue
> guaranteed-capacity (5/8ths for the high and the rest for the low). 
> However,
> the reduce jobs are not interleaved -- the reduce job in the high queue is
> blocked waiting for the reduce job in the low queue to complete.
>
> Is this a bug or by design?
>
> *Low queue:*
> Guaranteed Capacity (%) : 37.5
> Guaranteed Capacity Maps : 3
> Guaranteed Capacity Reduces : *3*
> User Limit : 100
> Reclaim Time limit : 300
> Number of Running Maps : 3
> Number of Running Reduces : *7*
> Number of Waiting Maps : 131
> Number of Waiting Reduces : 0
> Priority Supported : NO
>
> *High queue:*
> Guaranteed Capacity (%) : 62.5
> Guaranteed Capacity Maps : 5
> Guaranteed Capacity Reduces : 5
> User Limit : 100
> Reclaim Time limit : 300
> Number of Running Maps : 4
> Number of Running Reduces : *0*
> Number of Waiting Maps : 68
> Number of Waiting Reduces : *7*
> Priority Supported : NO
>