-
Couldn't load subscription status.
- Fork 9.1k
YARN-11878. AsyncDispatcher event queue backlog with millions of STAT… #8026
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
Performance Verification in ProductionWe tested this patch in a production YARN cluster and used Arthas to monitor RM node event handling performance via: monitor -c 5 org.apache.hadoop.yarn.server.resourcemanager.ResourceManager$NodeEventDispatcher handleResult:Before patch (with original YARN-11003 behavior): average NM heartbeat handling time ≈ 1.10 ms Conclusion:The patch removes unnecessary getCapability() calls when the Opportunistic container feature is disabled, reducing CPU overhead and improving event queue turnover rate. |
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
Description of PR
JIRA: YARN-11878. AsyncDispatcher event queue backlog with millions of STATUS_UPDATE events
Avoid costly ContainerStatusPBImpl.getCapability() calls in STATUS_UPDATE when Opportunistic containers are disabled
Background
This behavior was introduced by YARN-11003. to support Opportunistic containers optimization in the ResourceManager.
To implement that optimization,
StatusUpdateWhenHealthyTransitioncallsContainerStatusPBImpl.getCapability()during everySTATUS_UPDATEevent.This ensures container resource capability info is always available for scheduling decisions
when opportunistic containers are enabled.
However, in clusters where opportunistic containers are disabled,
retrieving
capabilityin everySTATUS_UPDATEbecomes unnecessary,since the capability value is not used in most workflows.
Currently
NodeManager heartbeat: frequent
STATUS_UPDATEevents sent to the ResourceManagerEach STATUS_UPDATE processing: triggers
ContainerStatusPBImpl.getCapability()Problem: Even when the opportunistic container feature is off, the same costly protobuf parsing and
ResourcePBImplobject construction still happens for each event. This leads to:Impact
In clusters with thousands of nodes,
STATUS_UPDATEevents can account for >90% of the AsyncDispatcher queue.Profiling shows that
getCapability()calls consume >90% of CPU time inStatusUpdateWhenHealthyTransition.transition()when opportunistic containers are disabled.The overhead is pure waste under these conditions and can be entirely skipped.
Proposed Changes
opportunisticContainersEnabledis false.remoteContainer.getCapability()result in a local variable to prevent multiple protobuf parsing calls within the same STATUS_UPDATE handling.How was this patch tested?
CI
For code changes:
LICENSE,LICENSE-binary,NOTICE-binaryfiles?