Return-Path: X-Original-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EFCFB105B1 for ; Thu, 3 Oct 2013 17:04:33 +0000 (UTC) Received: (qmail 4592 invoked by uid 500); 3 Oct 2013 17:04:24 -0000 Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org Received: (qmail 4460 invoked by uid 500); 3 Oct 2013 17:04:24 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 4453 invoked by uid 99); 3 Oct 2013 17:04:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Oct 2013 17:04:23 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sandy.ryza@cloudera.com designates 209.85.220.54 as permitted sender) Received: from [209.85.220.54] (HELO mail-pa0-f54.google.com) (209.85.220.54) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Oct 2013 17:04:16 +0000 Received: by mail-pa0-f54.google.com with SMTP id kx10so2881242pab.13 for ; Thu, 03 Oct 2013 10:03:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FGE24TS74obgqojIezTpauZKCNQCNJcDsC97obMN4zY=; b=dk0rRQjWeKJdz+m0qoZbh7oB1JKJXPPdQ2th6KXteJ3zzXVG2PCAraWXpDv1xyBlTM CG3QyJjEgUvACEla6zCp4WPicl32+K8FHIGlvKkuHPM99AnJrU3K+zwH7r8Mecg936U6 Fm9OQ4+5/ICTDdVInk4KGapdlo5CBhh8kbqJ2vfSz1EqFN0kWSGiZ+QLUsWHVMmQt1jQ iZJtCwG3FBedHmDLsTT2bq0TG0C6E7C42ju4vkWqQ0kIAzBKuynzRuvwG0PkBNhXTuj8 wXJNT2q/ezsMeA86CAOAkQiP9jXO5enwEB5eZuilGrhP6HKRLOi9nBDv5XqbJutclonl foGQ== X-Gm-Message-State: ALoCoQkNd2kvUMEOn1cyEYZwNePPtqii4flWLhOzUVd9cIByImhzmi9Y5rsMNkC44LkuLqig1to0 MIME-Version: 1.0 X-Received: by 10.67.4.197 with SMTP id cg5mr10643016pad.10.1380819835112; Thu, 03 Oct 2013 10:03:55 -0700 (PDT) Received: by 10.70.52.2 with HTTP; Thu, 3 Oct 2013 10:03:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Oct 2013 10:03:55 -0700 Message-ID: Subject: Re: Non data-local scheduling From: Sandy Ryza To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=047d7b16013dc5650504e7d92beb X-Virus-Checked: Checked by ClamAV on apache.org --047d7b16013dc5650504e7d92beb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andre, Try setting yarn.scheduler.capacity.node-locality-delay to a number between 0 and 1. This will turn on delay scheduling - here's the doc on how this works: For applications that request containers on particular nodes, the number of scheduling opportunities since the last container assignment to wait before accepting a placement on another node. Expressed as a float between 0 and 1, which, as a fraction of the cluster size, is the number of scheduling opportunities to pass up. The default value of -1.0 means don't pass up any scheduling opportunities. -Sandy On Thu, Oct 3, 2013 at 9:57 AM, Andr=E9 Hacker wro= te: > Hi, > > I have a 25 node cluster, running hadoop 2.1.0-beta, with capacity > scheduler (default settings for scheduler) and replication factor 3. > > I have exclusive access to the cluster to run a benchmark job and I wonde= r > why there are so few data-local and so many rack-local maps. > > The input format calculates 44 input splits and 44 map tasks, however, it > seems to be random how many of them are processed data locally. Here the > counters of my last tries: > > data-local / rack-local: > Test 1: data-local:15 rack-local: 29 > Test 2: data-local:18 rack-local: 26 > > I don't understand why there is not always 100% data local. This should > not be a problem since the blocks of my input file are distributed over a= ll > nodes. > > Maybe someone can give me a hint. > > Thanks, > Andr=E9 Hacker, TU Berlin > --047d7b16013dc5650504e7d92beb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andre,

Try setting yarn.schedu= ler.capacity.node-locality-delay to a number between 0 and 1. =A0This will = turn on delay scheduling - here's the doc on how this works:

For applications that request c= ontainers on particular nodes, the number of scheduling opportunities since= the last container assignment to wait before accepting a placement on anot= her node. Expressed as a float between 0 and 1, which, as a fraction of the= cluster size, is the number of scheduling opportunities to pass up. The de= fault value of -1.0 means don't pass up any scheduling opportunities.=A0

-Sandy


On Thu, Oct 3, 2013 at 9:57 AM, Andr= =E9 Hacker <andrephacker@gmail.com> wrote:
Hi,

I have a 25= node cluster, running hadoop 2.1.0-beta, with capacity scheduler (default = settings for scheduler) and replication factor 3.

I have exclusive access to the cluster to run a benchmark jo= b and I wonder why there are so few data-local and so many rack-local maps.=

The input format calculates 44 input splits and 44 map tasks= , however, it seems to be random how many of them are processed data locall= y. Here the counters of my last tries:

data-local / rack-= local:
Test 1: data-local:15 rack-local: 29
Test 2: data-= local:18 rack-local: 26

I don't understand= why there is not always 100% data local. This should not be a problem sinc= e the blocks of my input file are distributed over all nodes.

Maybe someone can give me a hint.
<= br>Thanks,
Andr=E9 Hacker, TU Berlin

--047d7b16013dc5650504e7d92beb--