オリジナルリンク：Linuxのcgroupのシリーズの深い理解（2）：楽しいCPU
記事はその含め、いくつかの基本的な概念のcgroupを紹介し CentOS 、デフォルトの設定とシステム管理ツール、および方法のcgroupリソース制御を説明するためのCPUの例。この記事では、特定の実施例により限定されるものでCGROUPする方法について説明します CPU パフォーマンス上の別のcgroupとセットを使用しての影響。
1.レビュー現在の情報のcgroup
システムの現在のcgroupの情報を表示するには、2つの方法があります。第一の方法は、を介している systemd-cgls コマンドを表示するために、それは上部のcgroupから全体のcgroupの階層ツリーとしてシステムに戻り slice 、次のようになります。
$ 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二つのサブスライスを次のuser-1000.slice と user-0.slice、各サブスライスIDは、ユーザ（使用されるUID名前に）、ユーザに属するスライスを認識することは容易です。例えば：それ以上の出力情報で見ることができることから user-1000.slice 、利用者のトムに属しているuser-0.slice ユーザーのルートに属しています。
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/[email protected] 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 コマンドが、コマンドのみを表示し、それらのリソースは、サービスと統計関数を開いてスライス。たとえば：開きたい場合は sshd.service 、リソースの統計機能を、次の操作を実行できます。
$ 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システムで、すべてのコントロールは、あなた自身の手の中にある、あなたはそれを行う方法でやってみたいです。
2. CPU割当時間相対
私たちは、CPUが知っている記事の研究を通じて、 shares 相対的なCPUの使用時間を設定するために使用することができ、その後、我々は実践を通して、それを確認する必要があります。
実施次の実験は、テキストの端を別々に説明する、マルチコアシングルコアが完全に異なっているシングルコアCPUシステム上で実行されます。
テスト・オブジェクトは、ユーザーサービスおよび2人の一般ユーザ、ある 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リソースを消費していきます。今、私たちは変更CPUシェアのfoo.serviceます 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倍。
3. 分配 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 资源的使用，防止对系统中其他重要的服务产生影响。
4. 动态设置 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，可以多折腾折腾这个目录。
5. 如果是多核 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 核，就要看它自身的设计支持不支持了。
6. 总结
本文通过具体的示例来观察不同的 cgroup 设置对性能的影响，下面一篇文章将会演示如何通过 cgroup 来限制内存的使用。