[
https://issues.apache.org/jira/browse/HADOOP-13362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370849#comment-15370849
]
Jason Lowe commented on HADOOP-13362:
-------------------------------------
Thanks for the pointer! Yes, it appears YARN-5190 fixed this as a side-effect
since it added the requisite methods to DefaultMetricsSystem.
You had mentioned in YARN-5296 that a part of YARN-1643 is needed since
metrics.finished() isn't being called, but I'm not sure that's necessary. In
the heap dump I didn't see any leak beyond the source names.
MetricsSystemImpl.unregisterSource is being called for each container, and once
YARN-5190 changes that method to unregister the source name from DefaultMetrics
I think we're OK at that point.
> DefaultMetricsSystem leaks the source name when a source unregisters
> --------------------------------------------------------------------
>
> Key: HADOOP-13362
> URL: https://issues.apache.org/jira/browse/HADOOP-13362
> Project: Hadoop Common
> Issue Type: Bug
> Components: metrics
> Affects Versions: 2.7.2
> Reporter: Jason Lowe
> Priority: Critical
>
> Ran across a nodemanager that was spending most of its time in GC. Upon
> examination of the heap most of the memory was going to the map of names in
> org.apache.hadoop.metrics2.lib.UniqueNames. In this case the map had almost
> 2 million entries. Looking at a few of the map showed entries like
> "ContainerResource_container_e01_1459548490386_8560138_01_002020",
> "ContainerResource_container_e01_1459548490386_2378745_01_000410", etc.
> Looks like the ContainerMetrics for each container will cause a unique name
> to be registered with UniqueNames and the name will never be unregistered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
