Linux systemd資源控制初探

本文記錄一次cgroup子目錄丟失問題，並簡單探索了Linux systemd的資源控制機制。

問題現象

我們希望通過systemd拉起服務並通過cgroup限制其CPU、memory的使用，因此我們新建了一個.service文件，文件里面創建了自己的cgroup目錄，設置了cpu、memory限制，然后通過cgexec拉起我們的服務進程。假設我們的服務叫xx，.service文件大概是這樣的：

[Unit]
Description=xx Server
Documentation=xx docs

[Service]
EnvironmentFile=-/etc/xx
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/memory/xx
ExecStartPre=/usr/bin/bash -c "echo 2G > /sys/fs/cgroup/memory/xx/memory.limit_in_bytes"
ExecStartPre=/usr/bin/bash -c "echo 2G > /sys/fs/cgroup/memory/xx/memory.memsw.limit_in_bytes"

ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpu/xx
ExecStartPre=/usr/bin/bash -c "echo 100000 > /sys/fs/cgroup/cpu/xx/cpu.cfs_period_us"
ExecStartPre=/usr/bin/bash -c "echo 100000 > /sys/fs/cgroup/cpu/xx/cpu.cfs_quota_us"
ExecStartPre=/usr/bin/bash -c "echo 1024 > /sys/fs/cgroup/cpu/xx/cpu.shares"

ExecStart=/usr/bin/cgexec -g cpu,memory:xx /usr/bin/xx

Restart=on-failure
KillMode=process
LimitNOFILE=102400
LimitNPROC=102400
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

設置完.service文件后，將其拷貝到/usr/lib/systemd/system目錄（CentOS 7）下，然后通過systemctl start xx.service啟動，通過systemctl enable xx.service關聯自啟動項。
但在運行很久之后，發現我們的xx服務內存使用爆了，然后查看我們自己創建的xx cgroup目錄丟失了，因此對應的CPU、memory資源也就沒有限制住。

分析過程

剛開始的定位過程是很懵逼的，各種日志查看沒有發現線索，嘗試復現也沒有成功。正在苦惱沒有方向之際，無意中發現執行了其他服務的systemd的某些操作（stop/start/enable）之后，復現了問題，就這樣盯上了systemd。
后來發現其實一開始就可以通過查看進程的cgroup信息就能很快找到線索：進程cgroup移到了/system.slice/xx.service目錄下：

[root@localhost ~]# cat /proc/214041/cgroup 
10:memory:/system.slice/xx.service
4:cpuacct,cpu:/system.slice/xx.service

而/system.slice/xx.service正是systemd為xx這個服務創建的cgroup目錄。所以問題鎖定為systemd把xx進程從我們自己創建的cgroup移動到它默認創建的cgroup里，但是它默認創建的cgroup顯然沒有設置過資源限制。

systemd資源控制

systemd通過Unit的配置文件配置資源控制，Unit包括services（上面例子就是一個service unit）, slices, scopes, sockets, mount points, 和swap devices六種。systemd底層也是依賴Linux Control Groups (cgroups)來實現資源控制。

cgroup v1和v2

cgroup有兩個版本，新版本的cgroup v2即Unified cgroup(參考cgroup v2)和傳統的cgroup v1（參考cgroup v1），在新版的Linux（4.x）上，v1和v2同時存在，但同一種資源（CPU、內存、IO等）只能用v1或者v2一種cgroup版本進行控制。systemd同時支持這兩個版本，並在設置時為兩者之間做相應的轉換。對於每個控制器，如果設置了cgroup v2的配置，則忽略所有v1的相關配置。
在systemd配置選項上，cgroup v2相比cgroup v1有如下不一樣的地方：
1.CPU： CPUWeight=和StartupCPUWeight=取代了CPUShares=和StartupCPUShares=。cgroup v2沒有"cpuacct"控制器。
2.Memory：MemoryMax=取代了MemoryLimit=. MemoryLow= and MemoryHigh=只在cgroup v2上支持。
3.IO：BlockIO前綴取代了IO前綴。在cgroup v2，Buffered寫入也統計在了cgroup寫IO里，這是cgroup v1一直存在的問題。

配置選項(新版本systemd)

CPUAccounting=：是否開啟該unit的CPU使用統計，BOOL型，true或者false。

CPUWeight=weight, StartupCPUWeight=weight：用於設置cgroup v2的cpu.weight參數。取值范圍1-1000，默認值100。StartupCPUWeight應用於系統啟動階段，CPUWeight應用於正常運行時。這兩個配置取代了舊版本的CPUShares=和StartupCPUShares=。

CPUQuota=：用於設置cgroup v2的cpu.max參數或者cgroup v1的cpu.cfs_quota_us參數。表示可以占用的CPU時間配額百分比。如：20%表示最大可以使用單個CPU核的20%。可以超過100%，比如200%表示可以使用2個CPU核。

MemoryAccounting=：是否開啟該unit的memory使用統計，BOOL型，true或者false。

MemoryLow=bytes：用於設置cgroup v2的memory.low參數，不支持cgroup v1。當unit使用的內存低於該值時將被保護，其內存不會被回收。可以設置不同的后綴：K,M,G或者T表示不同的單位。

MemoryHigh=bytes：用於設置cgroup v2的memory.high參數，不支持cgroup v1。內存使用超過該值時，進程將被降低運行時間，並快速回收其占用的內存。同樣可以設置不同的后綴：K,M,G或者T（單位1024）。也可以設置為infinity表示沒有限制。

MemoryMax=bytes：用於設置cgroup v2的memory.max參數，如果進程的內存超過該限制，則會觸發out-of-memory將其kill掉。同樣可以設置不同的后綴：K,M,G或者T（單位1024），以及設置為infinity。該參數去掉舊版本的MemoryLimit=。

MemorySwapMax=bytes：用於設置cgroup v2的memory.swap.max"參數。和MemoryMax類似，不同的是用於控制Swap的使用上限。

TasksAccounting=：是否開啟unit的task個數統計，BOOL型，ture或者false。

TasksMax=N：用於設置cgroup的pids.max參數。控制unit可以創建的最大tasks個數。

IOAccounting：是否開啟Block IO的統計，BOOL型，true或者false。對應舊版本的BlockIOAccounting=參數。

IOWeight=weight, StartupIOWeight=weight：設置cgroup v2的io.weight參數，控制IO的權重。取值范圍0-1000，默認100。該設置取代了舊版本的BlockIOWeight=和StartupBlockIOWeight=。

IODeviceWeight=device weight：控制單個設備的IO權重，同樣設置在cgroup v2的io.weight參數里，如“/dev/sda 1000”。取值范圍0-1000，默認100。該設置取代了舊版本的BlockIODeviceWeight=。

IOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes：設置磁盤IO讀寫帶寬上限，對應cgroup v2的io.max參數。該參數格式為“path bandwidth”，path為具體設備名或者文件系統路徑（最終限制的是文件系統對應的設備名）。數值bandwidth支持以K,M,G,T后綴（單位1000）。可以設置多行以限制對多個設備的IO帶寬。該參數取代了舊版本的BlockIOReadBandwidth=和BlockIOWriteBandwidth= 。

IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS：設置磁盤IO讀寫的IOPS上限，對應cgroup v2的io.max參數。格式和上面帶寬限制的格式一樣一樣的。

IPAccounting=：BOOL型，如果為true，則開啟ipv4/ipv6的監聽和已連接的socket網絡收發包統計。

IPAddressAllow=ADDRESS[/PREFIXLENGTH]…, IPAddressDeny=ADDRESS[/PREFIXLENGTH]…：開啟AF_INET和AF_INET6 sockets的網絡包過濾功能。參數格式為IPv4或IPv6的地址列表，IP地址后面支持地址匹配前綴（以'/'分隔），如”10.10.10.10/24“。需要注意，該功能僅在開啟“eBPF”模塊的系統上才支持。

DeviceAllow=：用於控制對指定的設備節點的訪問限制。格式為“設備名 權限”，設備名以"/dev/"開頭或者"char-"、“block-”開頭。權限為'r','w','m'的組合，分別代表可讀、可寫和可以通過mknode創建指定的設備節點。對應cgroup的"devices.allow"和"devices.deny"參數。

DevicePolicy=auto|closed|strict：控制設備訪問的策略。strict表示：只允許明確指定的訪問類型；closed表示：此外，還允許訪問包含/dev/null,/dev/zero,/dev/full,/dev/random,/dev/urandom等標准偽設備。auto表示：此外，如果沒有明確的DeviceAllow=存在，則允許訪問所有設備。auto是默認設置。

Slice=：存放unit的slice目錄，默認為system.slice。

Delegate=：默認關閉，開啟后將更多的資源控制交給進程自己管理。開啟后unit可以在單其cgroup下創建和管理其自己的cgroup的私人子層級，systemd將不在維護其cgoup以及將其進程從unit的cgroup里移走。開啟方法：“Delegate=yes”。所以通過設置Delegate選項，可以解決上面的問題。

配置選項（舊版本）

這些是舊版本的選項，新版本已經棄用。列出來是因為centos 7里的systemd是舊版本，所以要使用這些配置。

CPUShares=weight, StartupCPUShares=weight：進程獲取CPU運行時間的權重值，對應cgroup的"cpu.shares"參數，取值范圍2-262144，默認值1024。

MemoryLimit=bytes：進程內存使用上限，對應cgroup的"memory.limit_in_bytes"參數。支持K,M,G,T（單位1024）以及infinity。默認值-1表示不限制。

BlockIOAccounting=：開啟磁盤IO統計選項，同上面的IOAccounting=。

BlockIOWeight=weight, StartupBlockIOWeight=weight：磁盤IO的權重，對應cgroup的"blkio.weight"參數。取值范圍10-1000，默認值500。

BlockIODeviceWeight=device weight：指定磁盤的IO權重，對應cgroup的"blkio.weight_device"參數。取值范圍1-1000，默認值500。

BlockIOReadBandwidth=device bytes, BlockIOWriteBandwidth=device bytes：磁盤IO帶寬的上限配置，對應cgroup的"blkio.throttle.read_bps_device"和 "blkio.throttle.write_bps_device"參數。支持K,M,G,T后綴（單位1000）。

問題解決

回到上面的問題，我們可以通過兩種方法解決：
1.在unit配置文件里添加一個Delegate=yes的選項，這樣資源控制完全有用戶自己管理，systemd不會去移動進程到其默認創建的cgroup里。
2.直接使用systemd的資源控制機制進行資源控制。通過直接使用systemd的資源控制的.service配置文件樣例：

[Unit]
Description=xx Server

[Service]
ExecStart=/usr/bin/xx

LimitNOFILE=102400
LimitNPROC=102400
LimitCORE=infinity
Restart=on-failure
KillMode=process
MemoryLimit=1G
CPUShares=1024

[Install]
WantedBy=multi-user.target

修改完.service文件后，通過systemctl daemon-reload重新導入service文件，通過systemctl restart xx重啟服務。

總結

systemd有自己的資源控制機制，所以用systemd拉起的服務時，不要自作聰明創建自己的cgroup目錄並通過cgexec來拉起進程進行資源控制。

參考

systemd.resource-control
systemd for Administrators, Part XVIII
Control Group APIs and Delegation