Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-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 2F465185D0 for ; Sun, 23 Aug 2015 19:56:49 +0000 (UTC) Received: (qmail 17278 invoked by uid 500); 23 Aug 2015 19:56:44 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 17126 invoked by uid 500); 23 Aug 2015 19:56:44 -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 17115 invoked by uid 99); 23 Aug 2015 19:56:44 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Aug 2015 19:56:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id BA1F2C0332 for ; Sun, 23 Aug 2015 19:56:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.898 X-Spam-Level: *** X-Spam-Status: No, score=3.898 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id MKOLjWdbTJYs for ; Sun, 23 Aug 2015 19:56:41 +0000 (UTC) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 846AC20F19 for ; Sun, 23 Aug 2015 19:56:41 +0000 (UTC) Received: by obkg7 with SMTP id g7so96896410obk.3 for ; Sun, 23 Aug 2015 12:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=l03W/8dS7hXmZzN/ypyZG8Yi1urr3UQ63KAt8E8Z2EE=; b=0lutGZW86jSPnR84YEJKIxlAUajkro/g00H2s6q0/8HGtfxM54qkwlddHcXLQNYQFa x8fx5SRe6OgZ36ANtyLOiI2e363lVwVsrfbFD4OKbR5UEp5s3Mwma20cqVjqMMImgQW6 4vdXom3MPr9GadRjHWxki/7dVYgA4WslhJVriSwFaGI4RqjRrU7HgdFyC7moW4SwsP3B xZsbwim+laM9QSZdZLyk3v8jlF2Ah9tCr8RySN2BzMqKRP56zUDUzv4NB0Ro90SpoNPR yyM21hrx/ME9OSvmGwcyEkagoocOVDdrLaDyf3HMgyp/XbL33+Oo2K2Q7XcfbDHRyiNv m7Qg== MIME-Version: 1.0 X-Received: by 10.60.93.42 with SMTP id cr10mr18564092oeb.74.1440359800793; Sun, 23 Aug 2015 12:56:40 -0700 (PDT) Received: by 10.76.28.36 with HTTP; Sun, 23 Aug 2015 12:56:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Aug 2015 01:26:40 +0530 Message-ID: Subject: Re: yarn.nodemanager.resource.cpu-vcores vs yarn.scheduler.maximum-allocation-vcores From: Varun Saxena To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=047d7b33d42c466fe8051dffe6cf --047d7b33d42c466fe8051dffe6cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This configuration is read and used by NodeManager, on whichever node its running. If it is not configured, default value will be taken. Regards, Varun Saxena. On Mon, Aug 24, 2015 at 1:21 AM, Pedro Magalhaes wrote: > Thanks Varun! Like we say in Brazil. "U are the guy!" (Voc=C3=AA =C3=A9 = o cara!) > > I have another question. You said that: > "yarn.nodemanager.resource.cpu-vcores on the other hand will have to be > configured as per resource capability of that particular node. " > > I get the configuration from my job and printed it: > yarn.nodemanager.resource.cpu-vcores 8 yarn.nodemanager.resource.memory-m= b > 8192 > > So how does hadoop get this property if it is per node? Does it get the > minimum of all nodes? Thanks again! > > > > On Sun, Aug 23, 2015 at 4:40 PM, Varun Saxena > wrote: > >> The fix would be released in next version(2.8.0). >> I had checked the code to find out the default value and then found it >> fixed in documentation(configuration list). >> >> As this is an unreleased version, a URL link (of the form >> https://hadoop.apache.org/docs/r2.7.1/hadoop-yarn/hadoop-yarn-common/yar= n-default.xml) >> may not be available AFAIK, >> However, this XML(yarn-default.xml) can be checked online in git >> repository. >> >> Associated JIRA which fixes this is >> https://issues.apache.org/jira/browse/YARN-3823 >> >> Regards, >> Varun Saxena. >> >> On Mon, Aug 24, 2015 at 12:53 AM, Pedro Magalhaes >> wrote: >> >>> Thanks Varun! >>> Could plz send me the link with the fixed? >>> >>> On Sun, Aug 23, 2015 at 2:20 PM, Varun Saxena >>> wrote: >>> >>>> Hi Pedro, >>>> >>>> Real default value of yarn.scheduler.maximum-allocation-vcores is 4. >>>> The value of 32 is actually a documentation issue and has been fixed >>>> recently. >>>> >>>> Regards, >>>> Varun Saxena. >>>> >>>> >>>> On Sun, Aug 23, 2015 at 10:39 PM, Pedro Magalhaes >>>> wrote: >>>> >>>>> Varun, >>>>> Thanks for the reply. I undestand the arn.scheduler.maximum- >>>>> allocation-vcores parameter. I just asking why the default parameter >>>>> is yarn.scheduler.maximum-allocation-vcores=3D32. And >>>>> yarn.nodemanager.resource.cpu-vcores=3D8. >>>>> >>>>> In my opinion, if the yarn.scheduler.maximun-allocation-vcore is 32 >>>>> tby default the yarn.nodemanager.resource.cpu-vcores would be equal = or >>>>> greater than 32, by default. >>>>> Is this make sense? >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Aug 23, 2015 at 2:00 PM, Varun Saxena >>>> > wrote: >>>>> >>>>>> Hi Pedro, >>>>>> >>>>>> Actual allocation would depend on the total resource capability >>>>>> advertised by NM while registering with RM. >>>>>> >>>>>> yarn.scheduler.maximum-allocation-vcores merely puts an upper cap on= number of vcores which can be allocated by RM i.e. any Resource request/as= k from AM which asks for vcores > 32(default value) for a container, will b= e normalized back to 32. >>>>>> >>>>>> If there is no such node available, this allocation will not be fulf= illed. >>>>>> >>>>>> yarn.scheduler.maximum-allocation-vcores will be configured in >>>>>> resource manager and hence will be common for a cluster which can po= ssibly >>>>>> have multiple nodes with heterogeneous resource capabilities >>>>>> >>>>>> yarn.nodemanager.resource.cpu-vcores on the other hand will have to >>>>>> be configured as per resource capability of that particular node. >>>>>> >>>>>> Recently there has been work done to automatically get memory and CP= U >>>>>> information from underlying OS(supported OS being Linux and Windows)= if >>>>>> configured to do so. This change would be available in 2.8 >>>>>> I hope this answers your question. >>>>>> >>>>>> Regards, >>>>>> Varun Saxena. >>>>>> >>>>>> On Sun, Aug 23, 2015 at 9:40 PM, Pedro Magalhaes >>>>> > wrote: >>>>>> >>>>>>> I was looking at default parameters for: >>>>>>> >>>>>>> yarn.nodemanager.resource.cpu-vcores =3D 8 >>>>>>> yarn.scheduler.maximum-allocation-vcores =3D 32 >>>>>>> >>>>>>> For me this two parameters as default doesnt make any sense. >>>>>>> >>>>>>> The first one say "the number of CPU cores that can be allocated fo= r >>>>>>> containers." (I imagine that is vcore) The seconds says: "The maxim= um >>>>>>> allocation for every container request at the RM". In my opinion, t= he >>>>>>> second one must be equal or less than the first one. >>>>>>> >>>>>>> How can allocate 32 vcores for a container if i have only 8 cores >>>>>>> available per container? >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --047d7b33d42c466fe8051dffe6cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This configuration is read and used by NodeManager, on whi= chever node its running.
If it is not configured, default value will be= taken.

Regards,
Varun Saxena.

On Mon, Aug 24,= 2015 at 1:21 AM, Pedro Magalhaes <pedrorjbr@gmail.com> wr= ote:
Thanks Varun! Like = we say in Brazil. =C2=A0"U are the guy!" (Voc=C3=AA =C3=A9 o cara= !)

I have another question. You said that:
= "yarn.nodemanager.resource.cpu-vcores on the other hand will have to be configured as = per resource capability of that particular node.=C2=A0" =

I get the configuration from my job = and printed it:
yarn.= nodemanager.resource.cpu-vcores 8=20 yarn.nodemanager.resource.memory-mb 8192

So how does hadoop get this property if it is per node? Does it g= et the minimum of all nodes? Thanks again!



On Sun, Aug 23, 2015 = at 4:40 PM, Varun Saxena <vsaxena.varun@gmail.com> wro= te:
The fix would be rel= eased in next version(2.8.0).=C2=A0
I had checked the code to find out = the default value and then found it fixed in documentation(configuration li= st).=C2=A0



Regards,
Varun Saxena.

On Mon, Aug 24, 2015 at 12:53 AM, Pedro Magalhaes <= pedrorjbr@gmail.co= m> wrote:
= Thanks Varun!
Could plz send me the link with the fixed?

On Sun, Au= g 23, 2015 at 2:20 PM, Varun Saxena <vsaxena.varun@gmail.com>= wrote:
Hi Pedro,

Real default value of yarn.scheduler.maximum-allocati= on-vcores is 4.
The value of 32 is actually= a documentation issue and has been fixed recently.

Regards,
Varun Saxena.


On Sun, Aug 23= , 2015 at 10:39 PM, Pedro Magalhaes <pedrorjbr@gmail.com> = wrote:
Varun,
Thanks= for the reply. I undestand the=C2=A0arn.scheduler.maximum-allocation-vcores=C2=A0parameter. I just asking why = the default parameter is = yarn.scheduler.maximum-allocation-vcores=3D32.=C2=A0And=C2=A0yarn.nodemanager.resource.cpu-vcores=3D8.

In my opinion, if the yarn.scheduler.maximun-allocation-vcore is 32= tby default the yarn.nodemanager.resource.cpu-vcores =C2=A0would be equal = or greater than 32, by default.
Is this make sense?



On Sun, Aug 23, 2015 at 2:00 PM, Varun = Saxena <vsaxena.varun@gmail.com> wrote:
Hi Pedro,

Actual al= location would depend on the total resource capability advertised by NM whi= le registering with RM.
yarn.sche=
duler.maximum-allocation-vcores merely puts an upper cap on number of vcore=
s which can be allocated by RM i.e. any Resource request/ask from AM which =
asks for vcores > 32(default value) for a container, will be normalized =
back to 32.
If there is no such=
 node available, this allocation will not be fulfilled.
<= div>yarn.scheduler.maximum-allocation-vcores will be configured in resource= manager and hence will be common for a cluster which can possibly have mul= tiple nodes with heterogeneous resource capabilities

yarn.nodemanager.resource.cpu-vcores on the other hand will have to be c= onfigured as per resource capability of that particular node.=C2=A0

Recently there has been work done to automatically get me= mory and CPU information from underlying OS(supported OS being Linux and Wi= ndows) if configured to do so. This change would be available in 2.8
<= div>I hope this answers your question.

Regards,
Varun Saxena.

<= div class=3D"gmail_quote">On Sun, Aug 23, 2015 at 9:40 PM, Pedro Magalhaes = <pedrorjbr@gmail.com> wrote:

I was looking at default parameters for= :

yarn.nodemanager.resource.cpu-vcores =3D 8
yarn.scheduler.maximum-allocation-vcores =3D 32

For me this two parameters as default doesnt mak= e any sense.

The first one say "the number of CPU cor= es that can be allocated for containers." (I imagine that is vcore) Th= e seconds says: "The maximum allocation for every container request at= the RM". In my opinion, the second one must be equal or less than the= first one.

How can allocate 32 vcores for a container if = i have only 8 cores available per container?








--047d7b33d42c466fe8051dffe6cf--