上篇文章主要介紹了 cgroup 的一些基本概念，包括其在 CentOS 系統中的默認設置和控制工具，並以 CPU 為例闡述 cgroup 如何對資源進行控制。這篇文章將會通過具體的示例來演示如何通過 cgroup 來限制 CPU 的使用以及不同的 cgroup 設置對性能的影響。
1. 查看當前 cgroup 信息
有兩種方法來查看系統的當前 cgroup 信息。第一種方法是通過 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 下面有兩個子 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/getty@tty1.service 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 的資源統計功能，可以進行如下操作：
$ 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 的系統上進行的，多核與單核的情況完全不同，文末會單獨討論。
測試對象是 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倍。
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 來限制內存的使用。
