[
https://issues.apache.org/jira/browse/YARN-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163348#comment-14163348
]
Junping Du commented on YARN-2641:
----------------------------------
[~zxu], please see my comments inline.
bq. Did you still see the decommission happen after the heartbeat back to NM in
the patch?
I think the *actual* decommission happen when NM receive shutdown from RM
heartbeat back. Isn't it? So the latency between decommission CLI and node get
decommissioned won't affected. Also, in most cases, resource scheduling is
triggered by NM's heartbeat with RM. So the latency of decommission CLI and
scheduling container on nodes won't get affected (except attempt scheduling).
So IMO, this patch only improve the latency for attempt scheduling case. Do we
have some other scenarios to address?
> improve node decommission latency in RM.
> ----------------------------------------
>
> Key: YARN-2641
> URL: https://issues.apache.org/jira/browse/YARN-2641
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: resourcemanager
> Affects Versions: 2.5.0
> Reporter: zhihai xu
> Assignee: zhihai xu
> Attachments: YARN-2641.000.patch, YARN-2641.001.patch
>
>
> improve node decommission latency in RM.
> Currently the node decommission only happened after RM received nodeHeartbeat
> from the Node Manager. The node heartbeat interval is configurable. The
> default value is 1 second.
> It will be better to do the decommission during RM Refresh(NodesListManager)
> instead of nodeHeartbeat(ResourceTrackerService).
> This will be a much more serious issue:
> After RM is refreshed (refreshNodes), If the NM to be decommissioned is
> killed before NM sent heartbeat to RM. The RMNode will never be
> decommissioned in RM. The RMNode will only expire in RM after
> "yarn.nm.liveness-monitor.expiry-interval-ms"(default value 10 minutes) time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
