hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hitesh Sharma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-5501) Container Pooling in YARN
Date Thu, 23 Feb 2017 03:19:44 GMT

    [ https://issues.apache.org/jira/browse/YARN-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879783#comment-15879783

Hitesh Sharma commented on YARN-5501:

Hi [~asuresh], thanks for the feedback and sorry for the delay in responding.

bq. From the doc, it looks like "detach" implies removing the pre-initialized container from
the pool and "attach" referrs to associating an app with a pooled container. It might be simpler
if we treat the operation as atomic. In that sense, we can make do with just having an "attach"
or "lease", where a pre-initialized container is associated with an app.

Not sure what atomic means here but we need to detach so that the YARN machinery can be updated
to reflect the fact that the pre-initialized container was utilized. As part of this detaching
we also can associate the resources (files downloaded) by the pre-initialized container to
the actual application container that is going to use the pre-initialized container. This
ensures that when the application container exits then all resources for pre-initialized container
also get cleaned up.

bq. For the sake of simplicity. Maybe we should assume that once an application is assigned
a container from the pool and it has "attached" to it, it is the application's container and
the Pooling framework relinquishes ownership of. The container then completes normally and
all resource accounting is billed against the app. The pool of containers can be re-populated
externally by the pool manager component in the RM (beyond the scope of this currently)

Yes, agreed. We have the same thinking over here.

bq.  This is one of the reasons why I feel generalized resources would be useful here. Assume
initialy we have a cluster with resources <10 vcores, 10 GB> spread across 2 NMs equally.
Lets say we allocate 4 pre-initialized containers (via the pooling component in the RM) of
type foo each with <1 vcore, 1 GB>. Lets say's we distribute it equally across the NMs.
Once the pre-initialized containers have started, the total cluster resources would be <6
vcores, 6 GB, 4 foo>.
Each NM would have <3 vcores, 3 GB, 2 foo> available resources. Now if an app asks for
<0 vcores, 0 GB, 1 foo>, it will be allocated 1 pooled container and the resources associated
with 1 foo <1 vcore, 1 GB> can be accounted against the app. The app can also maybe
ask for <1 vcore, 1 GB, 1 foo>, in which case, the app will still be assigned one of
the pooled containers with the assumption that, the container's size can expand by <1 vcore,
1 GB> if required. Cgroups/JobObjects to be used to enforce this.


bq. AM Container communication.

In our PoC we introduced a new API in the container executor (attachContainer) which is called
when a pre-initialized container is used up by an actual AM. Either the ContainerExecutor
or the ContainerRuntime could be used for this purpose. But for now the application would
need to have a way for establishing communication with the pre-init container.

Thanks for the feedback guys. Appreciate the time and help.

> Container Pooling in YARN
> -------------------------
>                 Key: YARN-5501
>                 URL: https://issues.apache.org/jira/browse/YARN-5501
>             Project: Hadoop YARN
>          Issue Type: Improvement
>            Reporter: Arun Suresh
>            Assignee: Hitesh Sharma
>         Attachments: Container Pooling in YARN.pdf, Container Pooling - one pager.pdf
> This JIRA proposes a method for reducing the container launch latency in YARN. It introduces
a notion of pooling *Unattached Pre-Initialized Containers*.
> Proposal in brief:
> * Have a *Pre-Initialized Container Factory* service within the NM to create these unattached
> * The NM would then advertise these containers as special resource types (this should
be possible via YARN-3926).
> * When a start container request is received by the node manager for launching a container
requesting this specific type of resource, it will take one of these unattached pre-initialized
containers from the pool, and use it to service the container request.
> * Once the request is complete, the pre-initialized container would be released and ready
to serve another request.
> This capability would help reduce container launch latencies and thereby allow for development
of more interactive applications on YARN.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message