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

前言

在半年多之前的这篇文章中，笔者已经从源码层面讲解过了YARN是如何实现内存资源隔离的。但是只隔离内存还不够，我们在生产环境中经常可以发现有计算密集型任务争用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。

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/sec-relationships_between_subsystems_hierarchies_control_groups_and_tasks

为了方便用户操作，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可控制的方面很多，可以说是容器技术的鼻祖，在Docker、Kubernetes等框架中应用甚广。但YARN仅用它实现了CPU资源隔离，所以下面只是来认识一下CPU子系统。

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资源就会被浪费，鱼与熊掌不可兼得。

后记

写得还是有点乱的，主要是因为这块的内容本来条理就不太清楚…

写本文的契机还是来源于在社区大群里解答的问题。

民那晚安。

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 158,847评论 4赞 362
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,208评论 1赞 292
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 108,587评论 0赞 243
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,942评论 0赞 205
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,332评论 3赞 287
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,587评论 1赞 218
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,853评论 2赞 312
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,568评论 0赞 198
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,273评论 1赞 242
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,542评论 2赞 246
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,033评论 1赞 260
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,373评论 2赞 253
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,031评论 3赞 236
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,073评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,830评论 0赞 195
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,628评论 2赞 274
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,537评论 2赞 269