[
https://issues.apache.org/jira/browse/TEZ-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14949535#comment-14949535
]
Jason Lowe commented on TEZ-2872:
---------------------------------
The problem with TEZ-754 is that it only helps when containers are reused. It
would do nothing to help an initial rush of fresh containers and therefore is
only a partial solution. TEZ-1371 would help a bit more, assuming the
implementation was smart enough to avoid races where it sends to all containers
on a node _until_ at least one of them has received it. Otherwise it has the
same initial startup issue as TEZ-754. And given a large enough cluster
launching enough containers simultaneously, it still has startup issues.
TEZ-307 seems like an approach that can really solve the issue by preventing
the payload from becoming a per-RPC burden.
> Tez AM can be overwhelmed by TezTaskUmbilicalProtocol.getTask responses
> -----------------------------------------------------------------------
>
> Key: TEZ-2872
> URL: https://issues.apache.org/jira/browse/TEZ-2872
> Project: Apache Tez
> Issue Type: Bug
> Reporter: Jason Lowe
>
> When a large job runs on a large cluster with a large user payload then the
> AM can end up hitting OOM conditions. For example, Pig-on-Tez can require a
> significant user payload (approaching 1MB) for vertices, inputs, and outputs
> in the DAG. This can cause the ContainerTask response to be rather large per
> task, which can lead to a situation where the AM is generating output faster
> than the network interface can process it. If there are enough containers
> asking for tasks then this leads to an OOM condition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
