我们
开始研究 Red Hat Enterprise Linux 7中
的控制组 （Cgroups）-一种内核级机制，可让您控制系统资源的使用，简要研究了理论基础，现在着手管理CPU，内存和I / O资源的实践。
但是，在更改任何内容之前，找出所有内容的排列方式总是很有用的。
您可以使用两种工具查看系统中活动cgroup的状态。 首先，这是systemd-cgls-一个显示树状列表的cgroup和正在运行的进程的命令。 她的输出看起来像这样：
在这里，我们看到了顶级cgroup：user.slice和system.slice。 我们没有虚拟机，因此，在负载下，这些顶级组将接收50％的CPU资源（因为计算机片未处于活动状态）。 user.slice中有两个子切片：user-1000.slice和user-0.slice。 用户片由用户ID（UID）标识，因此，除了正在运行的进程外，很难标识所有者。 在我们的情况下，ssh会话分别显示用户1000是mrichter，用户0是root。
我们将使用的第二个命令是systemd-cgtop。 它显示了实时的资源使用情况（顺便说一句，systemd-ggls的输出也已实时更新）。 在屏幕上，看起来像这样：
systemd-cgtop存在一个问题-它仅显示那些启用了资源使用计费的服务和片的统计信息。 通过在/ etc / systemd / system中相应子目录中创建嵌入式conf文件来启用记帐。 例如，下面的屏幕快照中的下拉菜单启用了sshd服务的CPU和内存使用率。 为此，您只需在文本编辑器中创建相同的插件即可。 此外，还可以使用systemctl set-property sshd.service CPUAccounting = true命令MemoryAccounting = true启用计费。
创建该插件后，必须输入systemctl daemon-reload命令以及相应服务的systemctl restart <service_name>命令。 结果，您将看到有关资源使用情况的统计信息，但这会造成额外的负担，因为资源也将用于会计。 因此，应仔细考虑会计，并且仅针对需要以这种方式进行监视的那些服务和cgroup。 但是，通常可以使用top或iotop命令代替systemd-cgtop。
有趣地更改CPU球
现在，让我们看看处理器球的变化（CPU份额）如何影响性能。 例如，我们将有两个非特权用户和一个系统服务。 使用mrichter登录名的用户的UID为1000，可以使用/ etc / passwd文件进行验证。
这很重要，因为用户片是由UID而不是帐户名命名的。
现在，让我们遍历下拉目录，查看其片中是否已有任何内容。
不，什么都没有。 尽管还有其他内容-看看与foo.service相关的东西：
如果您熟悉systemd单位文件，那么您会在这里看到一个完全普通的单位文件，该文件将命令/ usr / bin / sha1sum / dev / zero作为服务运行（换句话说，是守护程序）。对我们而言，重要的是foo将采用从字面上看，系统将允许他使用的所有处理器资源。 另外，在这里我们为foo服务提供了一个插入设置，即CPU球的值等于2048。如您所记得，默认情况下，它与值1024一起使用，因此在负载下，foo将在system.slice中获得双倍的CPU资源份额。 ，其父顶级切片（因为foo是服务）。
现在通过systemctl运行foo，看看top命令向我们显示了什么：
由于系统中几乎没有其他工作，因此foo服务（pid 2848）几乎消耗了一个CPU的所有处理器时间。
现在让我们将mrichter引入用户方程式中。 首先，我们将他的CPU数减少到256，然后他登录并启动foo.exe，换句话说，是相同的程序，但作为用户进程。
于是mrichter推出了foo。 这是top命令现在显示的内容：
奇怪吧 用户mrichter似乎获得了大约10％的处理器时间，因为他的= 256球，而foo.service最多有2048个，不是吗？
现在我们将dorf引入方程。 这是另一个具有等于1024的标准CPU球的普通用户。他还将运行foo，我们将再次看到处理器时间的分配将如何变化。
dorf是个老派用户，他只是启动该过程，没有任何智能脚本或其他任何东西。 再来看一下top的输出：
所以...让我们看一下cgroups树，尝试找出是什么：
如果您还记得的话，通常在系统中有三个顶级cgroup：System，User和Machine。 由于在我们的示例中没有虚拟机，因此仅保留系统和用户片。 它们每个都有一个1024的CPU球，因此在负载下它将获得一半的处理器时间。 由于foo.service位于系统中，并且在此片中没有其他CPU时间候选者，因此foo.service接收50％的CPU资源。
此外，用户dorf和mrichter居住在“用户”片中。 第一个球是1024，第二个球是256。因此，dorf的处理器时间是mrichter的四倍。 现在，让我们看看上面显示的内容：foo.service-50％，dorf-40％，mrichter-10％。
将其翻译成用例语言，可以说dorf具有更高的优先级。 因此，对cgroup进行了配置，以便用户mrichter在他们需要的时间内削减资源。 的确，毕竟，尽管mrichter仅在系统中，但他获得了50％的处理器时间，因为在User片中没有其他人争夺CPU资源。
实际上，即使对于优先级较低的用户和服务，CPU球也是提供一定“保证的最小”处理器时间的方法。
另外，我们有一种方法可以为CPU资源设置硬配额，即绝对数量的特定限制。 我们将为用户提供更多信息，并查看资源分配如何变化。
现在，让我们杀死用户dorf的任务，这是发生的情况：
对于mrichter，绝对CPU限制为5％，因此foo.service获得了剩余的处理器时间。
继续欺负并停止foo.service：
我们在这里看到的是：mrichter拥有5％的处理器时间，其余95％的系统处于空闲状态。 正式的嘲讽，是的。
实际上，这种方法使您可以有效地平息喜欢突然摆动并将所有处理器资源拖到自己身上的服务或应用程序，从而损害其他进程。
因此，我们学习了如何使用cgroup控制当前情况。 现在我们更深入地研究一下，如何在虚拟文件系统级别实现cgroup。
所有正在运行的cgroup的根目录位于/ sys / fs / cgroup。 系统启动时，它将随着服务和其他任务的启动而填满。 启动和停止服务时，它们的子目录会出现并消失。
在下面的屏幕截图中，我们转到了CPU控制器的子目录，即“系统”片中。 如您所见，foo的子目录尚未出现。 运行foo并检查几件事，即其PID和当前的CPU球：
重要警告：这里您可以随时更改值。 是的，从理论上讲，它看起来很酷（实际上也是如此），但它可能会变成一团糟。 因此，在进行任何更改之前，请仔细权衡所有内容，不要在战斗服务器上玩游戏。 但是无论如何，在学习cgroup的工作方式时，虚拟文件系统是需要深入研究的东西。