大佬教程收集整理的这篇文章主要介绍了Cgroups 与 Systemd，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

考前文《》先了解 cgroups。当 Linux 的 init 系统发展到 systemd 之后，systemd 与 cgroups 发生了融合(或者说 systemd 提供了 cgroups 的使用和管理接口，systemd 管的东西越来越多啊！)。本文将简单的介绍 cgroups 与 systemd 的关系以及如何通过 systemd 来配置和使用 cgroups。

层级结构(A)和资源控制(B)。首先 cgroups 是以层级结构组织并标识进程的一种方式，同时它也是在该层级结构上执行资源限制的一种方式。我们简单的把 cgroups 的层级结构称为 A，把 cgrpups 的资源控制能力称为 B。

slice、scope 和 service unit 的层级(slice、scope 和 service 都是 systemd 的 unit 类型，参考《》)，来为 cgroup 树提供统一的层级结构。

• service： 一个或一组进程，由 systemd 依据 unit 配置文件启动。service 对指定进程进行封装，这样进程可以作为一个整体被启动或终止。
• scope：一组外部创建的进程。由进程通过 fork() 函数启动和终止、之后被 systemd 在运行时注册的进程，scope 会将其封装。例如：用户会话、 容器和虚拟机被认为是 scope。
• slice： 一组按层级排列的 unit。slice 并不包含进程，但会组建一个层级，并将 scope 和 service 都放置其中。真正的进程包含在 scope 或 service 中。在这一被划分层级的树中，每一个 slice 单位的名字对应通向层级中一个位置的路径。

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/856f5665e747ca6646d770cf313230d9.png" >

service、scope 和 slice unit 被直接映射到 cgroup 树中的对象。当这些 unit 被激活时，它们会直接一一映射到由 unit 名建立的 cgroup 路径中。例如，cron.service 属于 system.slice，会直接映射到 cgroup system.slice/cron.service/ 中。

• -.slice：根 slice
• system.slice：所有系统 service 的默认位置
• user.slice：所有用户会话的默认位置
• @machine.slice：所有虚拟机和 Linux 容器的默认位置

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/2ac64c4302b7d4898059ab86ac5ab250.png" >

如何创建临时的 cgroup。systemd-run 命令创建临时的 cgroup，它可以创建并启动临时的 service 或 scope unit，并在此 unit 中运行程序。systemd-run 命令默认创建 service 类型的 unit，比如我们创建名称为 toptest 的 service 运行 top 命令：

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/01a019465769b35013e562f07d8a2118.png" >

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/1062032503f94a53024146a30d7b33e0.png" >

service cgroup 层级关系。再看看 toptest.service 的状态：

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/110897d968ae842cb9990f879437b7d3.png" >

service 运行在后台了！

service 的资源了。在限制前让我们先来看一看 top 进程的 cgroup 信息：

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/50ca239c299d1af2633242667ca4aab1.png" >

service 的 CPUShares 为 600，可用内存的上限为 550M：

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/a1dd849d44a022b272707b2222c5d571.png" >

service 的名字。同时去查看 /sys/fs/cgroup/memory/test.slice 和 /sys/fs/cgroup/cpu/test.slice 目录，这两个目录下都多出了一个 toptest.service 目录。我们设置的 CPUShares=600 MemoryLimit=500M 被分别写入了这些目录下的对应文件中。

临时 cgroup 的特征是，所包含的进程一旦结束，临时 cgroup 就会被自动释放。比如我们 kill 掉 top 进程，然后再查看 /sys/fs/cgroup/memory/test.slice 和 /sys/fs/cgroup/cpu/test.slice 目录，刚才的 toptest.service 目录已经不见了。

p)都在 /usr/lib/systemd/system/ 目录中有一个 unit 配置文件。比如我们常见的 service 类型 unit 的配置文件。我们可以通过设置 unit 配置文件来控制应用程序的资源，persistent cgroup 的特点是即便系统重启，相关配置也会被保留。需要注意的是，scope unit 不能以此方式创建。service 添加 CPU 和内存相关的一些限制，编辑 /lib/systemd/system/cron.service 文件：

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/6c18f81df8349bf810a84c24f66ce54e.png" >

然后重新加载配置文件并重启 cron.service：

m.slice/cron.service/memory.limit_in_bytes 和 /sys/fs/cgroup/cpu/system.slice/cron.service/cpu.shares 文件，是不是已经包含我们配置的内容了！

service 的 CPUShares 改为 700：

m.slice/cron.service/cpu.shares 文件的内容应该是 700，重启系统后该文件的内容还是 700。

title="Cgroups 与 Systemd" alt="Cgroups 与 Systemd" src="@R_450_10107@s://cn.js-code.com/res/2019/02-09/09/ff9c6c9e523605dc59d751560c73a169.png" >

便利！Systemd 提供的内在机制、默认设置和相关的操控命令降低了配置和使用 cgroups 的难度，即便是 Linux 新手，也能轻松的使用 cgroups 了。

考：

大佬总结

以上是大佬教程为你收集整理的Cgroups 与 Systemd全部内容，希望文章能够帮你解决Cgroups 与 Systemd所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。