Another thing to be aware of is that YARN will round up containers to the
nearest increment of yarn.scheduler.minimum-allocation-mb, which defaults
to 1024.

-Sandy

On Sat, Dec 6, 2014 at 3:48 PM, Denny Lee <denny.g....@gmail.com> wrote:

> Got it - thanks!
>
> On Sat, Dec 6, 2014 at 14:56 Arun Ahuja <aahuj...@gmail.com> wrote:
>
>> Hi Denny,
>>
>> This is due the spark.yarn.memoryOverhead parameter, depending on what
>> version of Spark you are on the default of this may differ, but it should
>> be the larger of 1024mb per executor or .07 * executorMemory.
>>
>> When you set executor memory, the yarn resource request is executorMemory
>> + yarnOverhead.
>>
>> - Arun
>>
>> On Sat, Dec 6, 2014 at 4:27 PM, Denny Lee <denny.g....@gmail.com> wrote:
>>
>>> This is perhaps more of a YARN question than a Spark question but i was
>>> just curious to how is memory allocated in YARN via the various
>>> configurations.  For example, if I spin up my cluster with 4GB with a
>>> different number of executors as noted below
>>>
>>>  4GB executor-memory x 10 executors = 46GB  (4GB x 10 = 40 + 6)
>>>  4GB executor-memory x 4 executors = 19GB (4GB x 4 = 16 + 3)
>>>  4GB executor-memory x 2 executors = 10GB (4GB x 2 = 8 + 2)
>>>
>>> The pattern when observing the RM is that there is a container for each
>>> executor and one additional container.  From the basis of memory, it looks
>>> like there is an additional (1GB + (0.5GB x # executors)) that is allocated
>>> in YARN.
>>>
>>> Just wondering why is this  - or is this just an artifact of YARN itself?
>>>
>>> Thanks!
>>>
>>>
>>

Reply via email to