Return-Path: 
 <core-dev-return-61946-apmail-hadoop-core-dev-archive=hadoop.apache.org@hadoop.apache.org>
Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org
Received: (qmail 75119 invoked from network); 15 Feb 2009 00:48:25 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 15 Feb 2009 00:48:25 -0000
Received: (qmail 93140 invoked by uid 500); 15 Feb 2009 00:48:22 -0000
Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org
Received: (qmail 93095 invoked by uid 500); 15 Feb 2009 00:48:22 -0000
Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:core-dev-help@hadoop.apache.org>
List-Unsubscribe: <mailto:core-dev-unsubscribe@hadoop.apache.org>
List-Post: <mailto:core-dev@hadoop.apache.org>
List-Id: <core-dev.hadoop.apache.org>
Reply-To: core-dev@hadoop.apache.org
Delivered-To: mailing list core-dev@hadoop.apache.org
Received: (qmail 93082 invoked by uid 99); 15 Feb 2009 00:48:22 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Feb 2009 16:48:22 -0800
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 15 Feb 2009 00:48:20 +0000
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id B30C2234C48D
	for <core-dev@hadoop.apache.org>; Sat, 14 Feb 2009 16:47:59 -0800 (PST)
Message-ID: <2104663657.1234658879732.JavaMail.jira@brutus>
Date: Sat, 14 Feb 2009 16:47:59 -0800 (PST)
From: "Matei Zaharia (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-5262) Allow specifying min shares as
 percentage of cluster
In-Reply-To: <166567703.1234599119576.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org


    [ https://issues.apache.org/jira/browse/HADOOP-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673558#action_12673558 ] 

Matei Zaharia commented on HADOOP-5262:
---------------------------------------

I suggested we allow both modes because we have been using the fixed-number-of-slots model at Facebook. We mostly use min share to guarantee that ETL jobs and other jobs with deadlines get enough slots to finish in time. Thus it makes more sense to set the min share to something small but just enough to be sure that the job will finish, and this is easier to think of in terms of slots than percents. I understand that the Yahoo use case is different and requires assigning percent shares to organizations.

> Allow specifying min shares as percentage of cluster
> ----------------------------------------------------
>
>                 Key: HADOOP-5262
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5262
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: contrib/fair-share
>            Reporter: Matei Zaharia
>            Priority: Minor
>
> Currently the guaranteed shares for pools in the fair scheduler are specified as a number of slots. For organizations where a group pays X% of the cluster and the actual number of nodes in the cluster varies due to failures, expansion, etc over time, it would be useful to support a guaranteed share given as a percentage too. This would just let you write in the config file something like <minMaps>5%</minMaps> instead of <minMaps>42</minMaps>. The scheduler would need to recompute what this means in terms of number of slots on every update (probably through some kind of update(ClusterStatus) method in PoolManager).

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