cgroups 资源限制(二):组织结构与基本规则、子系统简介
- 1.组织结构与基本规则
- 2.子系统简介
1.组织结构与基本规则
在之前的博客已经介绍过,传统的 Unix 任务管理,实际上是先启动 init
任务作为根节点,再由 init
节点创建子任务作为子节点,而每个子节点又可以创建新的子节点,如此往复,形成一个树状结构。而系统中的多个 cgroup 也构成类似的树状结构,子节点从父节点继承属性。
它们最大的不同在于,系统中的多个 cgroup 构成的层级并非单根结构,可以允许存在多个。如果任务模型是由 init
作为根节点构成的一棵树,那么系统中的多个 cgroup 则是由多个层级构成的森林。这样做的目的很好理解,如果只有一个层级,那么所有的任务都将被迫绑定其上的所有子系统,这会给某些任务造成不必要的限制。在 Docker 中,每个子系统独自构成一个层级,这样做非常易于管理。
了解了 cgroups 的组织结构,再来了解 cgroups、任务、子系统、层级四者间的关系及其基本规则。
规则 1:同一个层级可以附加一个或多个子系统。如下图所示,CPU 和 Memory 的子系统附加到了一个层级。
规则 2:一个子系统可以附加到多个层级,当且仅当目标层级只有唯一一个子系统时。下图中小圈中的数字表示子系统附加的时间顺序,CPU 子系统附加到层级 A 的同时不能再附加到层级 B,因为层级 B 已经附加了内存子系统。如果层级 B 没有附加过内存子系统,那么 CPU 子系统同时附加到两个层级是允许的。
规则 3:系统每次新建一个层级时,该系统上的所有任务默认加入这个新建层级的初始化 cgroup,这个 cgroup 也被称为 root cgroup
。对于创建的每个层级,任务只能存在于其中一个 cgroup 中,即一个任务不能存在于同一个层级的不同 cgroup 中,但一个任务可以存在于不同层级中的多个 cgroup 中。如果操作时把一个任务添加到同一个层级中的另一个 cgroup 中,则会将它从第一个 cgroup 中移除。在下图中可以看到,httpd
任务已经加入到层级 A 中的 /cg1
,而不能加入同一个层级中的 /cg2
,但是可以加入层级 B 中的 /cg3
。
规则 4:任务在 fork/clone
自身时创建的子任务默认与原任务在同一个 cgroup 中,但是子任务允许被移动到不同的 cgroup 中。即 fork/clone
完成后,父子任务间在 cgroup 方面是互不影响的。下图中小圈中的数字表示任务出现的时间顺序,当 httpd
刚 fork
出另一个 httpd
时,两者在同一个层级中的同一个 cgroup 中。但是随后如果 ID 为 4840
的 httpd
需要移动到其他 cgroup 也是可以的,因为父子任务间已经独立。总结起来就是:初始化时子任务与父任务在同一个 cgroup,但是这种关系随后可以改变。
2.子系统简介
子系统实际上就是 cgroups 的资源控制系统,每种子系统独立地控制一种资源,目前 Docker 使用如下 9 种子系统,其中,net_cls
子系统在内核中已经广泛实现,但是 Docker 尚未采用,Docker 在网络方面的控制方式将在后续详细介绍,以下是它们的用途。
blkio
:可以为块设备设定输入 / 输出限制,比如物理驱动设备(包括磁盘、固态硬盘、USB 等)。cpu
:使用调度程序控制任务对 CPU 的使用。cpuacct
:自动生成 cgroup 中任务对 CPU 资源使用情况的报告。cpuset
:可以为 cgroup 中的任务分配独立的 CPU(此处针对多处理器系统)和内存。devices
:可以开启或关闭 cgroup 中任务对设备的访问。freezer
:可以挂起或恢复 cgroup 中的任务。memory
:可以设定 cgroup 中任务对内存使用量的限定,并且自动生成这些任务对内存资源使用情况的报告。perf _event
:使用后使 cgroup 中的任务可以进行统一的性能测试。net_cls
:Docker 没有直接使用它,它通过使用等级识别符(classid
)标记网络数据包,从而允许 Linux 流量控制程序(Traffic Controller
,TC
)识别从具体 cgroup 中生成的数据包。
上述子系统如何使用虽然很重要,但是 Docker 并没有对 cgroup 本身做增强,容器用户一般也不需要直接操作 cgroup,所以这里我们只大致说明一下操作流程,让大家有一个感性的认识。
Linux 中 cgroup 的实现形式表现为一个文件系统,因此需要 mount
这个文件系统才能够使用(也有可能已经 mount
好了),挂载成功后,就能看到各类子系统。
以 cpu
子系统为例,先看一下挂载了这个子系统的控制组下的文件。
在 /sys/fs/cgroup
的 cpu
子目录下创建控制组,控制组目录创建成后,它下面就会有很多类似的文件了。
下面的例子展示了如何限制 PID 为 18828
的进程的 cpu
使用配额:
>
和>>
其实都属于输出重定向,都可以输出内容到指定文件。
>
会覆盖目标的原有内容,当文件存在时,会先删除原文件,再重新创建文件,然后把内容写入该文件(即清空了原文件),否则直接创建文件。>>
会在目标原有内容后追加内容,当文件存在时直接在文件末尾进行内容追加,不会删除原文件,否则直接创建文件。
在 Docker 的实现中,Docker daemon 会在单独挂载了每一个子系统的控制组目录(比如 /sys/fs/cgroup/cpu
)下创建一个名为 docker
的控制组,然后在 docker
控制组里面,再为每个容器创建一个以容器 ID 为名称的容器控制组,这个容器里的所有进程的进程号都会写到该控制组 tasks
中,并且在控制文件(比如 cpu.cfs_quota_us
)中写入预设的限制参数值。综上,docker
组的层级结构如下。
关于 Docker 如何实现 cgroup 的配置的问题,将会在后续有关 libcontainer
的博客里解释。