[
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.
Agreed.
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 containers.
> * 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
