Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 4465 invoked from network); 10 Oct 2007 01:26:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Oct 2007 01:26:42 -0000 Received: (qmail 5950 invoked by uid 500); 10 Oct 2007 01:26:29 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 5911 invoked by uid 500); 10 Oct 2007 01:26:29 -0000 Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hadoop-dev@lucene.apache.org Delivered-To: mailing list hadoop-dev@lucene.apache.org Received: (qmail 5902 invoked by uid 99); 10 Oct 2007 01:26:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 18:26:29 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Oct 2007 01:26:41 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id B4C9E7141FE for ; Tue, 9 Oct 2007 18:25:50 -0700 (PDT) Message-ID: <4067188.1191979550692.JavaMail.jira@brutus> Date: Tue, 9 Oct 2007 18:25:50 -0700 (PDT) From: "Michael Bieniosek (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Updated: (HADOOP-1245) value for mapred.tasktracker.tasks.maximum taken from jobtracker, not tasktracker In-Reply-To: <17026046.1176250832475.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-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bieniosek updated HADOOP-1245: -------------------------------------- Description: I want to create a cluster with machines with different numbers of CPUs. Consequently, each machine should have a different value for mapred.tasktracker.tasks.maximum, since my map tasks are CPU bound. When a new job starts up, the jobtracker uses its (single) value for mapred.tasktracker.tasks.maximum to assign tasks. This means that each tasktracker gets the same number of tasks, regardless of how I configured that particular machine. The jobtracker should not consult its config for the value of mapred.tasktracker.tasks.maximum. It should assign tasks (or allow tasktrackers to request tasks) according to each tasktracker's value of mapred.tasktracker.tasks.maximum. Originally, I thought the behavior was slightly different, so this issue contained this text: After the first task finishes on each tasktracker, the tasktracker will request new tasks from the jobtracker according to the tasktracker's value for mapred.tasktracker.tasks.maximum. So after the first round of map tasks is done, the cluster reverts to a mode that works well for heterogeneous clusters. was: I want to create a cluster with machines with different numbers of CPUs. Consequently, each machine should have a different value for mapred.tasktracker.tasks.maximum, since my map tasks are CPU bound. However, hadoop uses BOTH the values for mapred.tasktracker.tasks.maximum on the jobtracker and the tasktracker. When a new job starts up, the jobtracker uses its (single) value for mapred.tasktracker.tasks.maximum to assign tasks. This means that each tasktracker gets the same number of tasks, regardless of how I configured that particular machine. After the first task finishes on each tasktracker, the tasktracker will request new tasks from the jobtracker according to the tasktracker's value for mapred.tasktracker.tasks.maximum. So after the first round of map tasks is done, the cluster reverts to a mode that works well for heterogeneous clusters. The jobtracker should not consult its config for the value of mapred.tasktracker.tasks.maximum. It should assign tasks (or allow tasktrackers to request tasks) according to each tasktracker's value of mapred.tasktracker.tasks.maximum. Summary: value for mapred.tasktracker.tasks.maximum taken from jobtracker, not tasktracker (was: value for mapred.tasktracker.tasks.maximum taken from two different sources) Fixing issue description to reflect reality as reported by others > value for mapred.tasktracker.tasks.maximum taken from jobtracker, not tasktracker > --------------------------------------------------------------------------------- > > Key: HADOOP-1245 > URL: https://issues.apache.org/jira/browse/HADOOP-1245 > Project: Hadoop > Issue Type: Bug > Components: mapred > Affects Versions: 0.12.3 > Reporter: Michael Bieniosek > Attachments: tasktracker-max-tasks-1245.patch > > > I want to create a cluster with machines with different numbers of CPUs. Consequently, each machine should have a different value for mapred.tasktracker.tasks.maximum, since my map tasks are CPU bound. > When a new job starts up, the jobtracker uses its (single) value for mapred.tasktracker.tasks.maximum to assign tasks. This means that each tasktracker gets the same number of tasks, regardless of how I configured that particular machine. > The jobtracker should not consult its config for the value of mapred.tasktracker.tasks.maximum. It should assign tasks (or allow tasktrackers to request tasks) according to each tasktracker's value of mapred.tasktracker.tasks.maximum. > Originally, I thought the behavior was slightly different, so this issue contained this text: > After the first task finishes on each tasktracker, the tasktracker will request new tasks from the jobtracker according to the tasktracker's value for mapred.tasktracker.tasks.maximum. So after the first round of map tasks is done, the cluster reverts to a mode that works well for heterogeneous clusters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.