[jira] [Commented] (YARN-10863) CGroupElasticMemoryController is not work
[ https://issues.apache.org/jira/browse/YARN-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452718#comment-17452718 ] LuoGe commented on YARN-10863: -- @chaosju please help to review it, thanks > CGroupElasticMemoryController is not work > - > > Key: YARN-10863 > URL: https://issues.apache.org/jira/browse/YARN-10863 > Project: Hadoop YARN > Issue Type: Bug > Components: nodemanager >Affects Versions: 3.3.1 >Reporter: LuoGe >Priority: Major > Attachments: YARN-10863.001-1.patch, YARN-10863.002.patch, > YARN-10863.004.patch, YARN-10863.005.patch, YARN-10863.006.patch, > YARN-10863.007.patch > > > When following the > [documentation|https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/NodeManagerCGroupsMemory.html] > configuring elastic memory resource control, > yarn.nodemanager.elastic-memory-control.enabled set true, > yarn.nodemanager.resource.memory.enforced set to false, > yarn.nodemanager.pmem-check-enabled set true, and > yarn.nodemanager.resource.memory.enabled set true to use cgroup control > memory, but elastic memory control is not work. > I see the code ContainersMonitorImpl.java, in checkLimit function, the skip > logic have some problem. The return condition is strictMemoryEnforcement is > true and elasticMemoryEnforcement is false. So, following the document set > use elastic memory control, the check logic will continue, when container > memory used over limit will killed by checkLimit. > {code:java} > if (strictMemoryEnforcement && !elasticMemoryEnforcement) { > // When cgroup-based strict memory enforcement is used alone without > // elastic memory control, the oom-kill would take care of it. > // However, when elastic memory control is also enabled, the oom killer > // would be disabled at the root yarn container cgroup level (all child > // cgroups would inherit that setting). Hence, we fall back to the > // polling-based mechanism. > return; > } > {code} -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] (YARN-10863) CGroupElasticMemoryController is not work
[ https://issues.apache.org/jira/browse/YARN-10863 ] LuoGe deleted comment on YARN-10863: -- was (Author: luoge): @chaosju please help to review it, thanks > CGroupElasticMemoryController is not work > - > > Key: YARN-10863 > URL: https://issues.apache.org/jira/browse/YARN-10863 > Project: Hadoop YARN > Issue Type: Bug > Components: nodemanager >Affects Versions: 3.3.1 >Reporter: LuoGe >Priority: Major > Attachments: YARN-10863.001-1.patch, YARN-10863.002.patch, > YARN-10863.004.patch, YARN-10863.005.patch, YARN-10863.006.patch, > YARN-10863.007.patch > > > When following the > [documentation|https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/NodeManagerCGroupsMemory.html] > configuring elastic memory resource control, > yarn.nodemanager.elastic-memory-control.enabled set true, > yarn.nodemanager.resource.memory.enforced set to false, > yarn.nodemanager.pmem-check-enabled set true, and > yarn.nodemanager.resource.memory.enabled set true to use cgroup control > memory, but elastic memory control is not work. > I see the code ContainersMonitorImpl.java, in checkLimit function, the skip > logic have some problem. The return condition is strictMemoryEnforcement is > true and elasticMemoryEnforcement is false. So, following the document set > use elastic memory control, the check logic will continue, when container > memory used over limit will killed by checkLimit. > {code:java} > if (strictMemoryEnforcement && !elasticMemoryEnforcement) { > // When cgroup-based strict memory enforcement is used alone without > // elastic memory control, the oom-kill would take care of it. > // However, when elastic memory control is also enabled, the oom killer > // would be disabled at the root yarn container cgroup level (all child > // cgroups would inherit that setting). Hence, we fall back to the > // polling-based mechanism. > return; > } > {code} -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10863) CGroupElasticMemoryController is not work
[ https://issues.apache.org/jira/browse/YARN-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452717#comment-17452717 ] LuoGe commented on YARN-10863: -- @chaosju please help to review it, thanks > CGroupElasticMemoryController is not work > - > > Key: YARN-10863 > URL: https://issues.apache.org/jira/browse/YARN-10863 > Project: Hadoop YARN > Issue Type: Bug > Components: nodemanager >Affects Versions: 3.3.1 >Reporter: LuoGe >Priority: Major > Attachments: YARN-10863.001-1.patch, YARN-10863.002.patch, > YARN-10863.004.patch, YARN-10863.005.patch, YARN-10863.006.patch, > YARN-10863.007.patch > > > When following the > [documentation|https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/NodeManagerCGroupsMemory.html] > configuring elastic memory resource control, > yarn.nodemanager.elastic-memory-control.enabled set true, > yarn.nodemanager.resource.memory.enforced set to false, > yarn.nodemanager.pmem-check-enabled set true, and > yarn.nodemanager.resource.memory.enabled set true to use cgroup control > memory, but elastic memory control is not work. > I see the code ContainersMonitorImpl.java, in checkLimit function, the skip > logic have some problem. The return condition is strictMemoryEnforcement is > true and elasticMemoryEnforcement is false. So, following the document set > use elastic memory control, the check logic will continue, when container > memory used over limit will killed by checkLimit. > {code:java} > if (strictMemoryEnforcement && !elasticMemoryEnforcement) { > // When cgroup-based strict memory enforcement is used alone without > // elastic memory control, the oom-kill would take care of it. > // However, when elastic memory control is also enabled, the oom killer > // would be disabled at the root yarn container cgroup level (all child > // cgroups would inherit that setting). Hence, we fall back to the > // polling-based mechanism. > return; > } > {code} -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-11028) Add metrics for container allocation latency
[ https://issues.apache.org/jira/browse/YARN-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Minni Mittal updated YARN-11028: Summary: Add metrics for container allocation latency (was: Add metrics for Guaranteed container allocation latency) > Add metrics for container allocation latency > > > Key: YARN-11028 > URL: https://issues.apache.org/jira/browse/YARN-11028 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Minni Mittal >Assignee: Minni Mittal >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Assigned] (YARN-10929) Refrain from creating new Configuration object in AbstractManagedParentQueue#initializeLeafQueueConfigs
[ https://issues.apache.org/jira/browse/YARN-10929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Teke reassigned YARN-10929: Assignee: Benjamin Teke (was: Szilard Nemeth) > Refrain from creating new Configuration object in > AbstractManagedParentQueue#initializeLeafQueueConfigs > --- > > Key: YARN-10929 > URL: https://issues.apache.org/jira/browse/YARN-10929 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: Benjamin Teke >Priority: Minor > Labels: pull-request-available > Time Spent: 2h > Remaining Estimate: 0h > > AbstractManagedParentQueue#initializeLeafQueueConfigs creates a new > CapacitySchedulerConfiguration with templated configs only. We should stop > doing this. > Also, there is a sorting of config keys in this method, but in the end the > configs are added to the Configuration object which is an enhanced Map. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10929) Refrain from creating new Configuration object in AbstractManagedParentQueue#initializeLeafQueueConfigs
[ https://issues.apache.org/jira/browse/YARN-10929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452416#comment-17452416 ] Benjamin Teke commented on YARN-10929: -- As per our offline discussion with [~snemeth] I'm taking this over. Uploaded a new PR. > Refrain from creating new Configuration object in > AbstractManagedParentQueue#initializeLeafQueueConfigs > --- > > Key: YARN-10929 > URL: https://issues.apache.org/jira/browse/YARN-10929 > Project: Hadoop YARN > Issue Type: Sub-task >Reporter: Szilard Nemeth >Assignee: Szilard Nemeth >Priority: Minor > Labels: pull-request-available > Time Spent: 2h > Remaining Estimate: 0h > > AbstractManagedParentQueue#initializeLeafQueueConfigs creates a new > CapacitySchedulerConfiguration with templated configs only. We should stop > doing this. > Also, there is a sorting of config keys in this method, but in the end the > configs are added to the Configuration object which is an enhanced Map. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-10863) CGroupElasticMemoryController is not work
[ https://issues.apache.org/jira/browse/YARN-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452256#comment-17452256 ] Hadoop QA commented on YARN-10863: -- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Logfile || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 36s{color} | {color:blue}{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green}{color} | {color:green} No case conflicting files found. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green}{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} {color} | {color:green} 0m 0s{color} | {color:green}test4tests{color} | {color:green} The patch appears to include 2 new or modified test files. {color} | || || || || {color:brown} trunk Compile Tests {color} || || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 21m 24s{color} | {color:green}{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 29s{color} | {color:green}{color} | {color:green} trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 25s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 34s{color} | {color:green}{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 47s{color} | {color:green}{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 14m 31s{color} | {color:green}{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s{color} | {color:green}{color} | {color:green} trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 37s{color} | {color:green}{color} | {color:green} trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 {color} | | {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 17m 9s{color} | {color:blue}{color} | {color:blue} Both FindBugs and SpotBugs are enabled, using SpotBugs. {color} | | {color:green}+1{color} | {color:green} spotbugs {color} | {color:green} 1m 21s{color} | {color:green}{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 39s{color} | {color:green}{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 22s{color} | {color:green}{color} | {color:green} the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 22s{color} | {color:green}{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 18s{color} | {color:green}{color} | {color:green} the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 18s{color} | {color:green}{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 25s{color} | {color:green}{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 39s{color} | {color:green}{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m 0s{color} | {color:green}{color} | {color:green} There were no new shellcheck issues. {color} | | {color:green}+1{color} | {color:green} shelldocs {color} | {color:green} 0m 19s{color} | {color:green}{color} | {color:green} There were no new shelldocs issues. {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green}{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 14m 3s{color} | {color:green}{color} | {color:green} patch has no errors when building and testing our client artifacts.