Cgroup

Cgroup理解

1、综述

1、cgroup 可以控制进程组的资源（cpu,memory,i/o等）

2、cgroup 采用树型结构来控制进程组的资源

3、cgroup 利用资源子系统来分割资源

4、cgroup 是lxc，docker等虚拟化技术的基石

2、cgroup基本概念

1、task任务，就是系统中的一个进程

2、control group 控制族群，一个进程组，cgroup控制资源的基本单位

3、hierarchy层级，控制族群有层级，子层级自动继承父层级的特性

4、subsystem子系统，资源控制器，它需要附着到一个层级上，一般是顶级层级

 

3、资源分配

在 CentOS 7 系统中（包括 Red Hat Enterprise Linux 7），通过将 cgroup 层级系统与 systemd 单位树捆绑，可以把资源管理设置从进程级别移至应用程序级别。默认情况下，systemd 会自动创建 slice、scope 和 service 单位的层级（具体的意思稍后再解释），来为 cgroup 树提供统一结构。可以通过 systemctl 命令创建自定义 slice 进一步修改此结构。

 

如果我们将系统的资源看成一块馅饼，那么所有资源默认会被划分为 3 个 cgroup：System, User和 Machine。每一个 cgroup 都是一个 slice，每个 slice 都可以有自己的子 slice，如下图所示：

 

下面我们以 CPU 资源为例，系统默认创建了 3 个顶级 slice（System, User 和 Machine），每个 slice 都会获得相同的 CPU 使用时间（仅在 CPU 繁忙时生效），如果 user.slice 想获得 100% 的 CPU 使用时间，而此时 CPU 比较空闲，那么 user.slice 就能够如愿以偿。这三种顶级 slice 的含义如下：

 

• system.slice —— 所有系统 service 的默认位置
• user.slice —— 所有用户会话的默认位置。每个用户会话都会在该 slice 下面创建一个子 slice，如果同一个用户多次登录该系统，仍然会使用相同的子 slice。

• machine.slice —— 所有虚拟机和 Linux 容器的默认位置

 

控制 CPU 资源使用的其中一种方法是 shares。shares 用来设置 CPU 的相对值（你可以理解为权重），并且是针对所有的 CPU（内核），默认值是 1024。因此在上图中，httpd, sshd, crond 和 gdm 的 CPU shares 均为 1024，System, User 和 Machine 的 CPU shares 也是 1024。

 

假设该系统上运行了 4 个 service，登录了两个用户，还运行了一个虚拟机。同时假设每个进程都要求使用尽可能多的 CPU 资源（每个进程都很繁忙）。

 

• system.slice 会获得 33.333% 的 CPU 使用时间，其中每个 service 都会从 system.slice 分配的资源中获得 1/4 的 CPU 使用时间，即 8.25% 的 CPU 使用时间。
• user.slice 会获得 33.333% 的 CPU 使用时间，其中每个登录的用户都会获得 16.5% 的 CPU 使用时间。假设有两个用户：tom 和 jack，如果 tom 注销登录或者杀死该用户会话下的所有进程，jack 就能够使用 33.333% 的 CPU 使用时间。

• machine.slice 会获得 33.333% 的 CPU 使用时间，如果虚拟机被关闭或处于 idle 状态，那么 system.slice 和 user.slice 就会从这 33.333% 的 CPU 资源里分别获得 50% 的 CPU 资源，然后均分给它们的子 slice。

 

如果想严格控制 CPU 资源，设置 CPU 资源的使用上限，即不管 CPU 是否繁忙，对 CPU 资源的使用都不能超过这个上限。可以通过以下两个参数来设置：

 

cpu.cfs_period_us = 统计CPU使用时间的周期，单位是微秒（us）

cpu.cfs_quota_us = 周期内允许占用的CPU时间(指单核的时间，多核则需要在设置时累加)

 

systemctl 可以通过 CPUQuota 参数来设置 CPU 资源的使用上限。例如，如果你想将用户 tom 的 CPU 资源使用上限设置为 20%，可以执行以下命令：

 

$ systemctl set-property user-1000.slice CPUQuota=20%

 

在使用命令 systemctl set-property 时，可以使用 tab 补全：

 

$ systemctl set-property user-1000.slice

AccuracySec= CPUAccounting= Environment= LimitCPU= LimitNICE= LimitSIGPENDING= SendSIGKILL= BlockIOAccounting= CPUQuota= Group= LimitDATA= LimitNOFILE= LimitSTACK= User= BlockIODeviceWeight= CPUShares= KillMode= LimitFSIZE= LimitNPROC= MemoryAccounting= WakeSystem= BlockIOReadBandwidth= DefaultDependencies= KillSignal= LimitLOCKS= LimitRSS= MemoryLimit= BlockIOWeight= DeviceAllow= LimitAS= LimitMEMLOCK= LimitRTPRIO= Nice= BlockIOWriteBandwidth= DevicePolicy= LimitCORE= LimitMSGQUEUE= LimitRTTIME= SendSIGHUP=

这里有很多属性可以设置，但并不是所有的属性都是用来设置 cgroup 的，我们只需要关注 Block, CPU 和 Memory。

 

如果你想通过配置文件来设置 cgroup，service 可以直接在 /etc/systemd/system/xxx.service.d 目录下面创建相应的配置文件，slice 可以直接在 /run/systemd/system/xxx.slice.d 目录下面创建相应的配置文件。事实上通过 systemctl 命令行工具设置 cgroup 也会写到该目录下的配置文件中：

 

$ cat /run/systemd/system/user-1000.slice.d/50-CPUQuota.conf

[Slice]

CPUQuota=20%

 

 

查看对应的 cgroup 参数：

$ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user-1000.slice/cpu.cfs_period_us

100000

 

$ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user-1000.slice/cpu.cfs_quota_us

20000

 

这表示用户 tom 在一个使用周期内（100 毫秒）可以使用 20 毫秒的 CPU 时间。不管 CPU 是否空闲，该用户使用的 CPU 资源都不会超过这个限制。

{{% notice note %}} CPUQuota 的值可以超过 100%，例如：如果系统的 CPU 是多核，且 CPUQuota 的值为 200%，那么该 slice 就能够使用 2 核的 CPU 时间。 {{% /notice %}}

 

4、cgroup 信息

有两种方法来查看系统的当前 cgroup 信息。第一种方法是经过 systemd-cgls 命令来查看，它会返回系统的总体 cgroup 层级，cgroup 树的最高层由 slice 构成，以下所示：bash

 

$ systemd-cgls --no-page

├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22

├─user.slice

│ ├─user-1000.slice

│ │ └─session-11.scope

│ │ ├─9507 sshd: tom [priv]

│ │ ├─9509 sshd: tom@pts/3

│ │ └─9510 -bash

│ └─user-0.slice

│ └─session-1.scope

│ ├─ 6239 sshd: root@pts/0

│ ├─ 6241 -zsh

│ └─11537 systemd-cgls --no-page

└─system.slice

├─rsyslog.service

│ └─5831 /usr/sbin/rsyslogd -n

├─sshd.service

│ └─5828 /usr/sbin/sshd -D

├─tuned.service

│ └─5827 /usr/bin/python2 -Es /usr/sbin/tuned -l -P

├─crond.service

│ └─5546 /usr/sbin/crond -n

 

能够看到系统 cgroup 层级的最高层由 user.slice 和 system.slice 组成。由于系统中没有运行虚拟机和容器，因此没有 machine.slice，因此当 CPU 繁忙时，user.slice 和 system.slice 会各得到 50% 的 CPU 使用时间。

 

user.slice 下面有两个子 slice：user-1000.slice 和 user-0.slice，每一个子 slice 都用 User ID (UID) 来命名，所以咱们很容易识别出哪一个 slice 属于哪一个用户。例如：从上面的输出信息中能够看出 user-1000.slice 属于用户 tom，user-0.slice 属于用户 root。

 

systemd-cgls 命令提供的只是 cgroup 层级的静态信息快照，要想查看 cgroup 层级的动态信息，能够经过 systemd-cgtop 命令查看：工具

 

$ systemd-cgtop

Path Tasks %CPU Memory Input/s Output/s

/ 161 1.2 161.0M - -

/system.slice - 0.1 - - -

/system.slice/vmtoolsd.service 1 0.1 - - -

/system.slice/tuned.service 1 0.0 - - -

/system.slice/rsyslog.service 1 0.0 - - -

/system.slice/auditd.service 1 - - - -

/system.slice/chronyd.service 1 - - - -

/system.slice/crond.service 1 - - - -

/system.slice/dbus.service 1 - - - -

/system.slice/gssproxy.service 1 - - - -

/system.slice/lvm2-lvmetad.service 1 - - - -

/system.slice/network.service 1 - - - -

/system.slice/polkit.service 1 - - - -

/system.slice/rpcbind.service 1 - - - -

/system.slice/sshd.service 1 - - - -

/system.slice/system-getty.slice/[e-mail] 1 - - - -

/system.slice/systemd-journald.service 1 - - - -

/system.slice/systemd-logind.service 1 - - - -

/system.slice/systemd-udevd.service 1 - - - -

/system.slice/vgauthd.service 1 - - - -

/user.slice 3 - - - -

/user.slice/user-0.slice/session-1.scope 3 - - - -

/user.slice/user-1000.slice 3 - - - -

/user.slice/user-1000.slice/session-11.scope 3 - - - -

/user.slice/user-1001.slice/session-8.scope 3 - - - -

 

systemd-cgtop 提供的统计数据和控制选项与 top 命令相似，但该命令只显示那些开启了资源统计功能的 service 和 slice。好比：若是你想开启 sshd.service 的资源统计功能，能够进行以下操做：post

 

$ systemctl set-property sshd.service CPUAccounting=true MemoryAccounting=true

 

该命令会在 /etc/systemd/system/sshd.service.d/ 目录下建立相应的配置文件：性能

 

$ ll /etc/systemd/system/sshd.service.d/

总用量 8

4 -rw-r--r-- 1 root root 28 5月 31 02:24 50-CPUAccounting.conf

4 -rw-r--r-- 1 root root 31 5月 31 02:24 50-MemoryAccounting.conf

$ cat /etc/systemd/system/sshd.service.d/50-CPUAccounting.conf

[Service]

CPUAccounting=yes

$ cat /etc/systemd/system/sshd.service.d/50-MemoryAccounting.conf

[Service]

MemoryAccounting=yes

 

 

配置完成以后，再重启 sshd 服务：学习

$ systemctl daemon-reload

$ systemctl restart sshd

 

这时再从新运行 systemd-cgtop 命令，就能看到 sshd 的资源使用统计了。开启资源使用量统计功能可能会增长系统的负载，由于资源统计也要消耗 CPU 和内存，大多数状况下使用 top 命令来查看就足够了。固然了，这是 Linux 系统嘛，一切的控制权都在你本身手里，你想怎么作就怎么作。

5、 分配 CPU 相对使用时间

CPU shares 能够用来设置 CPU 的相对使用时间，接下来咱们就经过实践来验证一下。

下面所作的实验都是在单核 CPU 的系统上进行的，多核与单核的状况彻底不一样，文末会单独讨论。

测试对象是 1 个 service 和两个普通用户，其中用户 tom 的 UID 是 1000，能够经过如下命令查看：

$ cat /etc/passwd|grep tom

tom:x:1000:1000::/home/tom:/bin/bash

 

建立一个 foo.service：

$ cat /etc/systemd/system/foo.service

[Unit]

Description=The foo service that does nothing useful

After=remote-fs.target nss-lookup.target

[Service]

ExecStart=/usr/bin/sha1sum /dev/zero

ExecStop=/bin/kill -WINCH ${MAINPID}

[Install]

WantedBy=multi-user.target

 

/dev/zero 在 linux 系统中是一个特殊的设备文件，当你读它的时候，它会提供无限的空字符，所以 foo.service 会不断地消耗 CPU 资源。如今咱们将 foo.service 的 CPU shares 改成 2048：

 

$ mkdir /etc/systemd/system/foo.service.d

$ cat << EOF > /etc/systemd/system/foo.service.d/50-CPUShares.conf

[Service]

CPUShares=2048

EOF

 

因为系统默认的 CPU shares 值为 1024，因此设置成 2048 后，在 CPU 繁忙的状况下，foo.service 会尽量获取 system.slice 的全部 CPU 使用时间。

如今经过 systemctl start foo.service 启动 foo 服务，并使用 top 命令查看 CPU 使用状况：

目前没有其余进程在消耗 CPU，因此 foo.service 可使用几乎 100% 的 CPU。

如今咱们让用户 tom 也参与进来，先将 user-1000.slice 的 CPU shares 设置为 256：

 

$ systemctl set-property user-1000.slice CPUShares=256

 

使用用户 tom 登陆该系统，而后执行命令 sha1sum /dev/zero，再次查看 CPU 使用状况：

如今是否是感到有点迷惑了？foo.service 的 CPU shares 是 2048，而用户 tom 的 CPU shares 只有 256，难道用户 tom 不是应该只能使用 10% 的 CPU 吗？回忆一下我在上一节提到的，当 CPU 繁忙时，user.slice 和 system.slice 会各得到 50% 的 CPU 使用时间。而这里刚好就是这种场景，同时 user.slice 下面只有 sha1sum 进程比较繁忙，因此会得到 50% 的 CPU 使用时间。

最后让用户 jack 也参与进来，他的 CPU shares 是默认值 1024。使用用户 jack 登陆该系统，而后执行命令 sha1sum /dev/zero，再次查看 CPU 使用状况：

上面咱们已经提到，这种场景下 user.slice 和 system.slice 会各得到 50% 的 CPU 使用时间。用户 tom 的 CPU shares 是 256，而用户 jack 的 CPU shares 是 1024，所以用户 jack 得到的 CPU 使用时间是用户 tom 的 4 倍。

 

6、分配 CPU 绝对使用时间

上篇文章已经提到，若是想严格控制 CPU 资源，设置 CPU 资源的使用上限，即无论 CPU 是否繁忙，对 CPU 资源的使用都不能超过这个上限，能够经过 CPUQuota 参数来设置。下面咱们将用户 tom 的 CPUQuota 设置为 5%：

$ systemctl set-property user-1000.slice CPUQuota=5%

 

这时你会看到用户 tom 的 sha1sum 进程只能得到 5% 左右的 CPU 使用时间。

若是此时中止 foo.service，关闭用户 jack 的 sha1sum 进程，你会看到用户 tom 的 sha1sum 进程仍然只能得到 5% 左右的 CPU 使用时间。

若是某个非核心服务很消耗 CPU 资源，你能够经过这种方法来严格限制它对 CPU 资源的使用，防止对系统中其余重要的服务产生影响。

7、 动态设置 cgroup

cgroup 相关的全部操做都是基于内核中的 cgroup virtual filesystem，使用 cgroup 很简单，挂载这个文件系统就能够了。系统默认状况下都是挂载到 /sys/fs/cgroup 目录下，当 service 启动时，会将本身的 cgroup 挂载到这个目录下的子目录。以 foo.service 为例：

先进入 system.slice 的 CPU 子系统：

$ cd /sys/fs/cgroup/cpu,cpuacct/system.slice

 

查看 foo.service 的 cgroup 目录：

$ ls foo.*

zsh: no matches found: foo.*

 

由于 foo.service 没有启动，因此没有挂载 cgroup 目录，如今启动 foo.service，再次查看它的 cgroup 目录：

$ ls foo.serice

cgroup.clone_children cgroup.procs cpuacct.usage cpu.cfs_period_us cpu.rt_period_us cpu.shares notify_on_release

cgroup.event_control cpuacct.stat cpuacct.usage_percpu cpu.cfs_quota_us cpu.rt_runtime_us cpu.stat tasks

 

也能够查看它的 PID 和 CPU shares：

$ cat foo.service/tasks

20225

$ cat foo.service/cpu.shares

2048

 

理论上咱们能够在 /sys/fs/cgroup 目录中动态改变 cgroup 的配置，但我不建议你在生产环境中这么作。若是你想经过实验来深刻理解 cgroup，能够多折腾折腾这个目录。

8、多核 CPU

上面的全部实验都是在单核 CPU 上进行的，下面咱们简单讨论一下多核的场景，以 2 个 CPU 为例。

首先来讲一下 CPU shares，shares 只能针对单核 CPU 进行设置，也就是说，不管你的 shares 值有多大，该 cgroup 最多只能得到 100% 的 CPU 使用时间(即 1 核 CPU)。仍是用本文第 2 节的例子，将 foo.service 的 CPU shares 设置为 2048，启动 foo.service，这时你会看到 foo.service 仅仅得到了 100% 的 CPU 使用时间，并无彻底使用两个 CPU 核：

再使用用户 tom 登陆系统，执行命令 sha1sum /dev/zero，你会发现用户 tom 的 sha1sum 进程和 foo.service 各使用 1 个 CPU 核：

再来讲说 CPUQuota，这个上篇文章结尾已经提过了，如要让一个 cgroup 彻底使用两个 CPU 核，能够经过 CPUQuota 参数来设置。例如：

$ systemctl set-property foo.service CPUQuota=200%

 

至于进程最后能不能彻底使用两个 CPU 核，就要看它自身的设计支持不支持了。

 

总结：CPUShares 用来设置相对权重，CPUQuota 用来限制 user、service 或 VM 的 CPU 使用时间百分比。例如：如果一个 user 同时设置了 CPUShares 和 CPUQuota，假设 CPUQuota 设置成 50%，那么在该 user 的 CPU 使用量达到 50% 之前，可以一直按照 CPUShares 的设置来使用 CPU。