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
>