1.文档编写目的
首先说明什么场景下适合使用CGroup，为什么会在集群YARN 中对CPU 进行Vcore数超配的情况下同样一个作业，同样的资源参数，有时候处理很快，有时候处理很慢，出现作业的运行效率无法预估情况？
当我们期望通过合理分配CPU的使用率，使应用预期性能的运行，排除其他因素的影响下，如应用中每分配一个Vcore，预估它能处理多少数据，就需要启用CGroup对CPU进行严格的使用率限制来实现。
在混合工作负载的示例是运行 MapReduce 和 Storm-on-YARN 的集群。MapReduce不受CPU限制（MapReduce 容器不需要太多CPU）,Storm-on-YARN 受 CPU 限制：其容器要求的CPU多于内存。当开始添加 Storm 作业和 MapReduce 作业时，DRF 调度程序会尝试平衡内存和 CPU 资源，但是随着更多 CPU 密集型 Storm 作业的添加，它们可能会开始占用大部分集群 CPU 资源。这时可以启用CGroup与CPU 调度一起使用来帮助管理混合工作负载。CGroups为诸如 Storm-on-YARN 之类的 CPU 密集型进程提供隔离，从而使我们能够以可预测的方式规划和约束CPU密集型Storm容器的CPU使用率。
当启用CGroup对CPU最大使用率进行限制时，即使有额外的CPU可用，每个资源也只会获得它所要求的资源。这种场景对于涉及退款或严格SLA实施的场景很有用，因为在这些场景中，我们需要准确了解应用正在使用的CPU百分比并保障所分配的CPU始终可用性。
- 测试环境
1.CDP7.1.4 、启用Kerberos、物理机28核(超线程56core)
2.操作步骤
2.1未启用CGroup和验证
前置条件：spark.dynamicAllocation.enabled=false，取消动态资源分配并更新到客户端配置，避免应用程序分配过多的CPU，影响判断。
使用spark pi 程序测试仅启用1个Vcore用于查看CPU使用率(后续的验证也都使用该用例)
代码语言：javascript复制spark-submit --class org.apache.spark.examples.SparkPi
--master yarn-client
--num-executors 1
--driver-memory 512m
--executor-memory 512m
--executor-cores 1
/opt/cloudera/parcels/CDH-7.1.4-1.cdh7.1.4.p0.6300266/jars/spark-examples_2.11-2.4.0.7.1.4.0-203.jar 1000场景1：
CGroup未启用，虚拟核跟物理核分配分配为1:1(这也是常用的配置)，提交spark 作业后，在Spark History Server 界面上找到该Application > 查看Executors > Active 的Executor 在cdpdevpubdn01 节点 确认Vcore 分配为1，到该节点执行 如下命令：
代码语言：javascript复制#查找该程序的进程
ps -ef | grep application_1623411625770_0971
#使用top -p 命令查看进程ID的CPU使用率
top -p 23578
确认在未启用CGroup的情况下单个Vcore的使用率可以超过100%。
场景2：
Cgroup 未启用，虚拟核分配分配为物理核2.5倍(当集群要求并发高时可以超配Vcore的数量实现更多的并发)
代码语言：javascript复制#查找该程序的进程
ps -ef | grep application_1623411625770_0974
#使用top -p 命令查看进程ID的使用率
top -p 18484
单个Vcore的使用率也可以超过100%，如果集群中CPU 使用率高的场景较多的情况下，因为超配的情况，就会出现即使有些作业能够分配Vcore，但是却没有实际物理cpu资源可调度，从而导致应用慢的情况。
2.2启用CGroup 和验证
启用Cgroup ，配置如下在CM > YARN > 配置 启用cgroup，修改如下参数
代码语言：javascript复制yarn.nodemanager.linux-container-executor.resources-handler.class=true
yarn.nodemanager.container-executor.class=true
yarn.nodemanager.linux-container-executor.cgroups.strick-resouce-usage=true
在YARN服务> 配置> yarn-site.xml YARN服务高级参数配置代码段(安全阀)
代码语言：javascript复制<property>
<name>yarn.nodemanager.resource.count-logical-processors-as-cores</name>
<value>true</value>
<description>是否将虚拟核当cpu 核心数</description>
</property>
<property>
<name>yarn.nodemanager.resource.detect-hardware-capabilities</name>
<value>true</value>
<description>YARN 自动探测CPU和内存</description>
</property>
<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>-1</value>
<description>关闭虚拟vcore配置，如物理机有启用超线程不关闭该参数无法读取到超线程核数</description>
</property>
<property><name>yarn.nodemanager.resource.pcores-vcores-multiplier</name>
<value>2.5</value>
<description>物理核与vcore的配比倍数</description>
</property>
CM>主机>配置>启用基于 Cgroup 的资源管理>勾选
然后保存并重启集群生效。
检查如下，运行的应用程序cgroups目录默认在/var/lib/yarn-ce/cgroups/cpu/hadoop-yarn 目录下
然后运行，在2.5倍Vcore的配置下，CPU使用率一直在40%左右，符合期望值。
如果启用CGroup限制成功那么理论值应该在40%，理论CPU最大使用率= 物理core数量/ Vcore数量*100%
比如我集群的物理core数量是100核，配置的Vcore数量是2.5倍。那么每个Vcore的CPU最大使用率是 100/250*100%=40%，如果配置的Vcore数量是2倍，那么那么每个Vcore的CPU最大使用率是 100/200*100%=50%
2.3 误区
通常在CDH集群中我们使用CM在YARN上配置yarn.nodemanager.resource.cpu-vcores参数来设置Vcore数量，根据实际测试中，该参数在启用CGroup 后是无法读取到物理机的超线程核数的(虽然在YARN中看到的可用Vcore数量是正确的)。建议的做法是如上 在YARN服务> 配置> yarn-site.xml YARN服务高级参数配置代码段(安全阀)配置yarn.nodemanager.resource.pcores-vcores-multiplier 的倍数来实现Vcore数量的配置。在Apache Hadoop 官网中关于这块的解释如下面参数所示：
https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml参数 | 默认值 | 详细说明 |
|---|---|---|
yarn.nodemanager.resource.cpu-vcores | -1 | Number of vcores that can be allocated for containers. This is used by the RM scheduler when allocating resources for containers. This is not used to limit the number of CPUs used by YARN containers. If it is set to -1 and yarn.nodemanager.resource.detect-hardware-capabilities is true, it is automatically determined from the hardware in case of Windows and Linux. In other cases, number of vcores is 8 by default. |
yarn.nodemanager.resource.count-logical-processors-as-cores | false | Flag to determine if logical processors(such as hyperthreads) should be counted as cores. Only applicable on Linux when yarn.nodemanager.resource.cpu-vcores is set to -1 and yarn.nodemanager.resource.detect-hardware-capabilities is true. |
yarn.nodemanager.resource.pcores-vcores-multiplier | 1.0 | Multiplier to determine how to convert phyiscal cores to vcores. This value is used if yarn.nodemanager.resource.cpu-vcores is set to -1(which implies auto-calculate vcores) and yarn.nodemanager.resource.detect-hardware-capabilities is set to true. The number of vcores will be calculated as number of CPUs * multiplier. |
我们也做了如下验证，也证明了在启用CGroup后 yarn.nodemanager.resource.cpu-vcores参数配置无法识别超线程核心数，如果未使用YARN服务> 配置> yarn-site.xml YARN服务高级参数配置代码段(安全阀)配置，而是使用yarn.nodemanager.resource.cpu-vcores参数来设置Vcore来实现Vcore的超配。在2.5倍超配的配置下，CPU使用率一直在20%左右。理论值应该在40%
在2倍超配的配置下，CPU使用率一直在25%左右。理论值应该在40%
3.总结
启用CGroup对CPU的最大使用率进行限制，可以使作业性能可预测(比如预估Spark Streaming 作业中每个executor的Vcore可以处理数据量的大小)。在分配同样的cpu下，如果不设置严格CPU使用率限制，则CPU密集型作业在集群未大量使用时运行得更快(例如所表现的情况是同样CPU资源分配下，Spark Streaming 作业中每个executor的Vcore可以处理数据量的大)，但在集群中运行更多作业时运行速度较慢（可能的风险是例如同样CPU资源分配下Spark Streaming 作业中每个executor的Vcore可以处理数据量的小，导致数据堆积从而导致应用失败）。另外，在基准测试启用CGroup 进行严格的CPU限制也很有作用。
参考文档：
https://docs.cloudera.com/cdp-private-cloud-base/7.1.4/yarn-allocate-resources/topics/yarn-using-cgroups.html
