[ 
https://issues.apache.org/jira/browse/YARN-6384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943704#comment-15943704
 ] 

Miklos Szegedi commented on YARN-6384:
--------------------------------------

bq. This may be confused, the 
yarn.nodemanager.resource.percentage-physical-cpu-limit can limit sum of 
cpu-usage of all containers, but there has no upper limit for each container. 
If you look at CGroupsCpuResourceHandlerImpl.preStart it does exactly what you 
are missing, a limit per each container:
{code}
      if (strictResourceUsageMode) {
        if (nodeVCores != containerVCores) {
          float containerCPU =
              (containerVCores * yarnProcessors) / (float) nodeVCores;
          int[] limits = getOverallLimits(containerCPU);
          cGroupsHandler.updateCGroupParam(CPU, cgroupId,
              CGroupsHandler.CGROUP_CPU_PERIOD_US, String.valueOf(limits[0]));
          cGroupsHandler.updateCGroupParam(CPU, cgroupId,
              CGroupsHandler.CGROUP_CPU_QUOTA_US, String.valueOf(limits[1]));
        }
      }
{code}

> Add configuratin to set max cpu usage when strict-resource-usage is false 
> with cgroups
> --------------------------------------------------------------------------------------
>
>                 Key: YARN-6384
>                 URL: https://issues.apache.org/jira/browse/YARN-6384
>             Project: Hadoop YARN
>          Issue Type: Improvement
>            Reporter: dengkai
>
> When using cgroups on yarn, if 
> yarn.nodemanager.linux-container-executor.cgroups.strict-resource-usage is 
> false, user may get very more cpu time than expected based on the vcores. 
> There should be a upper limit even resource-usage is not strict, just like a 
> percentage which user can get more than promised by vcores. I think it's 
> important in a shared cluster.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to