查看原文
其他

浅谈Linux cgroup机制与YARN的CPU资源隔离

大数据技术与架构点击右侧关注,大数据开发领域最强公众号!

暴走大数据点击右侧关注,暴走大数据!


前言

我们在生产环境中经常可以发现有计算密集型任务争用NodeManager的CPU,以及个别Container消耗太多CPU资源导致其他系统服务抖动的情况。好在Hadoop 2.2版本之后,YARN通过利用Linux系统的cgroup机制支持了CPU资源隔离。本文先简单看看cgroup,然后分析一下YARN的CPU资源隔离的方案。

简单入门cgroup

cgroup(control group)机制在Linux Kernel 2.6.24引入,主要用来限制与隔离进程组的资源——包括CPU、内存、磁盘、网络等,也可以用于控制优先级、统计资源用量、挂起与恢复进程。

从用户的角度看,一个cgroup就是一组按某种资源控制的标准划分的进程(task)。cgroup被组织成树形结构,称为层级(hierarchy),使得子cgroup可以继承父cgroup的部分控制属性。同时每个层级又会与一个或多个子系统(subsystem)关联,子系统会在该层级的所有树节点上执行具体的资源控制操作。也就是说,子系统实际扮演着资源控制器的角色。

内核为每种资源都定义了子系统,功能各自不同,举例如下。

  • cpu子系统:限制进程的CPU使用率;

  • cpuacct子系统:统计进程的CPU使用报告;

  • cpuset子系统:将进程绑定到指定的CPU或内存节点;

  • memory子系统:限制进程的内存使用率,并统计进程的内存使用报告;

  • blkio子系统:限制进程的块设备I/O速率;

  • devices子系统:指定进程可以访问哪些设备;

  • net_cls子系统:标记进程收发的数据包,进而用tc限制网络流量。

下图示出有两个层级的cgroup结构,其中层级A关联了cpu和memory两个子系统,层级B关联了net_cls子系统。注意图中的红色小叉,它表示同一个进程可以属于不同的层级,但是不能同时属于同一个层级的两个cgroup。

为了方便用户操作,cgroup通过VFS向用户提供文件系统接口(如同/proc一样)。执行mount -t cgroup命令可以查看已挂载的cgroup对应各个子系统的目录。这里系统版本是CentOS 7,cgroup的根目录是/sys/fs/cgroup;CentOS 6则是/cgroup。

~ mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)

cgroup的CPU子系统

在CPU子系统的根目录下创建一个新的cgroup目录,会自动生成一些文件。

~ cd /sys/fs/cgroup/cpu
~ mkdir cg_test
~ ls -1 cg_test
cgroup.clone_children
cgroup.event_control
cgroup.procs
cpuacct.stat
cpuacct.usage
cpuacct.usage_percpu
cpu.cfs_period_us
cpu.cfs_quota_us
cpu.rt_period_us
cpu.rt_runtime_us
cpu.shares
cpu.stat
notify_on_release
tasks

最主要的几个文件及它们的含义列举如下。

  • tasks
    保存有该cgroup内包含的PID列表,可以动态增减。

  • cpu.cfs_period_us
    表示CPU时间片的调度周期,单位为微秒,默认值100000(即100毫秒)。其中CFS一词代表"
    Completely Fair Scheduler",即内核中的完全公平进程调度器。

  • cpu.cfs_quota_us
    表示给这个cgroup里的进程分配的CPU时间片的长度,单位为微秒,默认值-1(即不限制)。举个例子,如果cpu.cfs_period_us=100000,且cpu.cfs_quota_us=200000,就表示该cgroup的进程最多可以使用200%的CPU;如果cpu.cfs_quota_us=50000,就表示最多可以使用50%的CPU。

  • cpu.shares
    表示cgroup内进程占用CPU权重的相对比例,默认值1024。举个例子,组A的cpu.shares=1024,组B的cpu.shares=2048,那么当两个cgroup中的进程都满负载运行时,组B能占用的CPU资源就是组A的两倍。如果有一方负载较低时,另一方还可以利用空闲的CPU资源。可见,它是比上述两个参数更为弹性化的限制。

  • cpu.stat
    保存有该cgroup的CPU资源的统计信息,包含cgroup创建开始经过的CPU周期,以及被cgroup限制掉的CPU周期和时间长度。

cgroup的层级关系就靠目录结构表示。如果我们在cg_test目录下再新建cg_test_sub1、cg_test_sub2目录,那么这两个cgroup就是cg_test的子节点,以此类推。

来操作一下吧。先用Python跑一个死循环,然后top之,发现该进程占用100%的CPU。

~ echo 'while True: pass' | python &
[1] 15054
~ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15054 root 20 0 123356 4476 1952 R 100.0 0.0 0:14.74 python

然后将刚才创建的cg_test组的cpu.cfs_quota_us值改为30000,并将该进程的PID写入tasks,再top之,就会看到它的CPU占用降低到了30%。


~ echo 30000 > /sys/fs/cgroup/cpu/cg_test/cpu.cfs_quota_us
~ echo 15054 > /sys/fs/cgroup/cpu/cg_test/tasks
~ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15054 root 20 0 123356 4476 1952 R 29.9 0.0 1:54.17 python

YARN CPU资源隔离实现

要启用YARN的CPU资源隔离,就得在yarn-site.xml里设定以下两个参数。更加详细的设定(如cgroup层级和路径等)请参考官方文档

yarn.nodemanager.container-executor.class: org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor
yarn.nodemanager.linux-container-executor.resources-handler.class: org.apache.hadoop.yarn.server.nodemanager.util.CgroupsLCEResourcesHandler

我们需要使用LinuxContainerExecutor来替代默认的DefaultContainerExecutor,因为前者会以YARN App提交者的身份执行创建和销毁Container的动作,并且支持cgroup机制。另外,还需要配置与它配套的支持cgroup的资源处理器类,即CgroupsLCEResourcesHandler。

接下来翻翻源码。在启动Container的LinuxContainerExecutor.launchContainer()方法中,调用了CgroupsLCEResourcesHandler.preExecute()方法初始化资源限制。

public void preExecute(ContainerId containerId, Resource containerResource)
throws IOException {
setupLimits(containerId, containerResource);
}

private void setupLimits(ContainerId containerId,
Resource containerResource) throws IOException {
String containerName = containerId.toString();

if (isCpuWeightEnabled()) {
int containerVCores = containerResource.getVirtualCores();
createCgroup(CONTROLLER_CPU, containerName);
int cpuShares = CPU_DEFAULT_WEIGHT * containerVCores;
updateCgroup(CONTROLLER_CPU, containerName, "shares",
String.valueOf(cpuShares));
if (strictResourceUsageMode) {
int nodeVCores =
conf.getInt(YarnConfiguration.NM_VCORES,
YarnConfiguration.DEFAULT_NM_VCORES);
if (nodeVCores != containerVCores) {
float containerCPU =
(containerVCores * yarnProcessors) / (float) nodeVCores;
int[] limits = getOverallLimits(containerCPU);
updateCgroup(CONTROLLER_CPU, containerName, CPU_PERIOD_US,
String.valueOf(limits[0]));
updateCgroup(CONTROLLER_CPU, containerName, CPU_QUOTA_US,
String.valueOf(limits[1]));
}
}
}
}

setupLimits()方法首先将单个Container申请的虚拟核心数记为containerVCores,然后调用createCgroup()方法创建包含Container名称的cgroup文件目录,也就是说一个Container对应一个cgroup。然后根据containerVCores设定这个cgroup的cpu.shares值(乘以默认值1024),即申请核心数越多,可占用的CPU资源比例越大。

接下来检查yarn.nodemanager.resource.percentage-physical-cpu-limit参数是否为true。若为true,表示启用了严格限制模式,需要设置cpu.cfs_period_us和cpu.cfs_quota_us。

使用containerVCores * yarnProcessors / nodeVCores推导出单个Container对应的物理核心数,其中yarnProcessors表示NodeManager所在节点的可用物理核心数(即总核心数乘以参数yarn.nodemanager.resource.percentage-physical-cpu-limit指定的百分比比例),nodeVCores表示单个NodeManager的虚拟核心数。

最后就是getOverallLimits()方法了。

int[] getOverallLimits(float yarnProcessors) {

int[] ret = new int[2];

if (yarnProcessors < 0.01f) {
throw new IllegalArgumentException("Number of processors can't be <= 0.");
}

int quotaUS = MAX_QUOTA_US;
int periodUS = (int) (MAX_QUOTA_US / yarnProcessors);
if (yarnProcessors < 1.0f) {
periodUS = MAX_QUOTA_US;
quotaUS = (int) (periodUS * yarnProcessors);
if (quotaUS < MIN_PERIOD_US) {
LOG
.warn("The quota calculated for the cgroup was too low. The minimum value is "
+ MIN_PERIOD_US + ", calculated value is " + quotaUS
+ ". Setting quota to minimum value.");
quotaUS = MIN_PERIOD_US;
}
}

// cfs_period_us can't be less than 1000 microseconds
// if the value of periodUS is less than 1000, we can't really use cgroups
// to limit cpu
if (periodUS < MIN_PERIOD_US) {
LOG
.warn("The period calculated for the cgroup was too low. The minimum value is "
+ MIN_PERIOD_US + ", calculated value is " + periodUS
+ ". Using all available CPU.");
periodUS = MAX_QUOTA_US;
quotaUS = -1;
}

ret[0] = periodUS;
ret[1] = quotaUS;
return ret;
}

可见,YARN采用了固定cpu.cfs_quota_us值(为1000000,即1秒),而改变cpu.cfs_period_us值的方式。cpu.cfs_period_us的值恰好是cpu.cfs_quota_us除以上面计算出来的单个Container对应的物理核心数,所以核心数越多的Container,cpu.cfs_period_us越小,可利用的CPU资源就越多。

最后再举个例子。假设NodeManager可用物理核心数为4(即总CPU资源为400%),虚拟核心数为6,根据上述算法,考虑3种情况。

  • 启动4个Container,每个Container申请1*vCore——普通模式每个Container分配100%,严格模式每个Container分配67%;

  • 启动2个Container,A申请2*vCore,B申请1*vCore——普通模式为A分配200%,B分配100%,严格模式为A分配133%,B分配67%。

  • 启动4个Container,A组两个申请2*vCore,B组两个申请1*vCore——两种模式均为为A组分配133%,B分配67%。

由上面的分析我们可以看出,cpu.share方式相当于"soft limit",用于控制Container使用CPU资源的下限,并且更加灵活,总体资源利用率高,但无法完全避免不稳定因素。而cpu.cfs_period_us+cfs_quota_us方式相当于"hard limit",严格限制了Container使用CPU资源的上限,显然更加稳定,但是在低负载的场景下,CPU资源就会被浪费,鱼与熊掌不可兼得。

——END——

文章不错?点个【在看】吧! 👇

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存