cgroupによるメモリ制御

お疲れ様です。mnakamuraです。

今回はcgroupについて書かせていただきます。
とはいえ文章量の都合上、全てを網羅することは難しい為、
その中でもメモリ制御について記載いたします。

説明に使用するmnakamuraの検証サーバはAlmaLinux8.7です。

[root@mnakamuraAlmaTest ~]# cat /etc/redhat-release
AlmaLinux release 8.7 (Stone Smilodon)

まずcgroupとは、プロセスをグループに分けてリソースをコントロールする、
コントロールグループ(Control Group)の略です。

占有サーバは兎も角、共有サーバは、複数ユーザでリソースを共有しています。
例えば、他ユーザが大量にリソースを使用しているせいで、
自分のユーザが思うように処理を実行できない…なんて事があると、納得できないと思います。
cgroupの機能を上手く利用して、制御できないでしょうか。

cgroupの仕組みとして、各種リソース毎のコントローラがカーネル内に存在します。

CPUコントローラ: CPUの使用時間の制御等
memoryコントローラ: メモリの使用量や、OOMKillerについての制御等
blkioコントローラ: ストレージI/Oの帯域制御等
networkコントローラ: ネットワークI/Oの帯域制御等

各種のファイルシステムをこれらのコントローラを介して使用するのですが、
下記の領域に格納されています。

[root@mnakamuraAlmaTest ~]# ll /sys/fs/cgroup/
合計 0
dr-xr-xr-x 3 root root 0 12月 20 00:22 blkio
lrwxrwxrwx 1 root root 11 12月 20 00:22 cpu -> cpu,cpuacct
dr-xr-xr-x 3 root root 0 12月 20 00:22 cpu,cpuacct
lrwxrwxrwx 1 root root 11 12月 20 00:22 cpuacct -> cpu,cpuacct
dr-xr-xr-x 2 root root 0 12月 20 00:22 cpuset
dr-xr-xr-x 3 root root 0 12月 20 00:22 devices
dr-xr-xr-x 2 root root 0 12月 20 00:22 freezer
dr-xr-xr-x 2 root root 0 12月 20 00:22 hugetlb
dr-xr-xr-x 5 root root 0 12月 20 00:22 memory
lrwxrwxrwx 1 root root 16 12月 20 00:22 net_cls -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 12月 20 00:22 net_cls,net_prio
lrwxrwxrwx 1 root root 16 12月 20 00:22 net_prio -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 12月 20 00:22 perf_event
dr-xr-xr-x 5 root root 0 12月 20 00:22 pids
dr-xr-xr-x 2 root root 0 12月 20 00:22 rdma
dr-xr-xr-x 5 root root 0 12月 20 00:22 systemd

今回は例として、cgroupの機能を利用して、
OOM Killerという、メモリ枯渇時に、
使用メモリリソースが多いプロセスを自動停止させる機能を弄ってみましょう。

まず比較する為に、cgroupを使わずに制御する方法を一つご紹介しますと、
各プロセスには「oom_score_adj」という、OOM Killerがプロセスを停止する際、
基準となる評価値の補正を司るものが存在します。
こちらは-1000から1000の範囲で、低い値である程停止されにくくなり、
最低である-1000では絶対に停止されなくなります。

※Linuxカーネルバージョンにもよりますが、
　AlmaLinux8.7では上記のようです

これらは /proc 領域配下にて、プロセス毎に用意されています。

[root@mnakamuraAlmaTest ~]# ll -A /proc/*/oom_score_adj | head
-rw-r–r– 1 root root 0 12月 20 00:22 /proc/1/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/10/oom_score_adj
-rw-r–r– 1 root root 0 12月 20 00:22 /proc/1075/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/1077/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/1096/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/11/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/12/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/13/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/14/oom_score_adj
-rw-r–r– 1 root root 0 12月 29 00:29 /proc/15/oom_score_adj

/proc 領域配下に、各PIDの領域があり、
その配下に「oom_score_adj」がある事が確認できます。
試しに、dockerのプロセスPIDを確認してみましょう。

[root@mnakamuraAlmaTest ~]# ps auxww | grep docker
root 1075 0.0 3.7 1358256 75008 ? Ssl 12月20 1:00 /usr/bin/dockerd -H fd:// –containerd=/run/containerd/containerd.sock
root 69361 0.0 0.0 10316 1196 pts/0 S+ 00:35 0:00 grep –color=auto docker

[root@mnakamuraAlmaTest ~]# systemctl status docker
● docker.service – Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2022-12-20 00:22:33 JST; 1 weeks 2 days ago
Docs: https://docs.docker.com
Main PID: 1075 (dockerd)
Tasks: 8
Memory: 109.9M
CGroup: /system.slice/docker.service
mq1075 /usr/bin/dockerd -H fd:// –containerd=/run/containerd/containerd.sock

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

PIDは1075です。

[root@mnakamuraAlmaTest ~]# cat /proc/1075/oom_score_adj
-500

-500で設定されています。この値を変更してみましょう。

[root@mnakamuraAlmaTest ~]# echo “-1000” > /proc/1075/oom_score_adj
[root@mnakamuraAlmaTest ~]# cat /proc/1075/oom_score_adj
-1000

-1000を設定しました。これでOOM Killerから停止させられる恐れはありません。
コアなプロセスはこれで守る事が出来ます。
例えば、使用量の多くなりがちなプロセスがサーバ内で複数ある場合は、
他のものから停止されるようコントロール可能なわけです。
ただし、一つ一つのプロセスを個別に細かく制御するならともかく、
複数のプロセスを制御したい場合はかなり手間がかかってしまいます。

次に、cgroupの機能で一括制御する一例を見てみましょう。
まずmemoryコントローラ領域を確認します。

[root@mnakamuraAlmaTest ~]# ll /sys/fs/cgroup/memory/
合計 0
-rw-r–r– 1 root root 0 12月 29 00:41 cgroup.clone_children
–w–w–w- 1 root root 0 12月 29 00:41 cgroup.event_control
-rw-r–r– 1 root root 0 12月 29 00:41 cgroup.procs
-r–r–r– 1 root root 0 12月 29 00:41 cgroup.sane_behavior
drwxr-xr-x 2 root root 0 12月 20 00:22 init.scope
-rw-r–r– 1 root root 0 12月 29 00:41 memory.failcnt
–w——- 1 root root 0 12月 29 00:41 memory.force_empty
-rw-r–r– 1 root root 0 12月 29 00:41 memory.kmem.failcnt
-rw-r–r– 1 root root 0 12月 20 00:22 memory.kmem.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:41 memory.kmem.max_usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:41 memory.kmem.slabinfo
-rw-r–r– 1 root root 0 12月 29 00:41 memory.kmem.tcp.failcnt
-rw-r–r– 1 root root 0 12月 20 00:22 memory.kmem.tcp.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:41 memory.kmem.tcp.max_usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:41 memory.kmem.tcp.usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:41 memory.kmem.usage_in_bytes
-rw-r–r– 1 root root 0 12月 20 00:22 memory.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:41 memory.max_usage_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:41 memory.memsw.failcnt
-rw-r–r– 1 root root 0 12月 20 00:22 memory.memsw.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:41 memory.memsw.max_usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:41 memory.memsw.usage_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:41 memory.move_charge_at_immigrate
-r–r–r– 1 root root 0 12月 29 00:41 memory.numa_stat
-rw-r–r– 1 root root 0 12月 20 00:22 memory.oom_control
———- 1 root root 0 12月 29 00:41 memory.pressure_level
-rw-r–r– 1 root root 0 12月 20 00:22 memory.soft_limit_in_bytes
-r–r–r– 1 root root 0 12月 29 00:41 memory.stat
-rw-r–r– 1 root root 0 12月 20 00:22 memory.swappiness
-r–r–r– 1 root root 0 12月 29 00:41 memory.usage_in_bytes
-rw-r–r– 1 root root 0 12月 20 00:22 memory.use_hierarchy
-rw-r–r– 1 root root 0 12月 29 00:41 notify_on_release
-rw-r–r– 1 root root 0 12月 29 00:41 release_agent
drwxr-xr-x 68 root root 0 12月 20 00:22 system.slice
-rw-r–r– 1 root root 0 12月 29 00:41 tasks
drwxr-xr-x 3 root root 0 12月 20 00:22 user.slice

様々なファイルが用意されていますが、
例えば「memory.limit_in_bytes」は各プロセスが使用可能なメモリ上限を設定しています。

[root@mnakamuraAlmaTest ~]# cat /sys/fs/cgroup/memory/memory.limit_in_bytes
9223372036854771712

この上限が適用されるプロセスは「tasks」にて、PIDを記載するような形で管理されています。

[root@mnakamuraAlmaTest ~]# cat /sys/fs/cgroup/memory/tasks
2
3
4
6
8
9
10
11
12
13
14
15
16
17
18
19
20
22
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
43
76
178
179
180
181
183
184
297
439
441
442
444
445
473
474
681
31105
68478
69185
69299
69318
69359
69385

おや？先程確認した、1075が存在しません。
実はtasksは、この領域から更に配下の領域毎にも存在するんですね。
更に下の領域である /sys/fs/cgroup/memory/system.slice/ を確認してみましょう。

[root@mnakamuraAlmaTest ~]# ll /sys/fs/cgroup/memory/system.slice/
合計 0
drwxr-xr-x 2 root root 0 12月 20 00:22 -.mount
drwxr-xr-x 2 root root 0 12月 20 00:22 NetworkManager-wait-online.service
drwxr-xr-x 2 root root 0 12月 20 00:22 NetworkManager.service
drwxr-xr-x 2 root root 0 12月 20 00:22 atd.service
-rw-r–r– 1 root root 0 12月 29 00:48 cgroup.clone_children
–w–w–w- 1 root root 0 12月 29 00:48 cgroup.event_control
-rw-r–r– 1 root root 0 12月 29 00:48 cgroup.procs
drwxr-xr-x 2 root root 0 12月 20 00:22 chronyd.service
drwxr-xr-x 2 root root 0 12月 20 00:22 containerd.service
drwxr-xr-x 2 root root 0 12月 20 00:22 crond.service
drwxr-xr-x 2 root root 0 12月 20 00:22 dbus.service
drwxr-xr-x 2 root root 0 12月 20 00:22 dbus.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 ‘dev-disk-by\x2duuid-814f1c0b\x2dbcfa\x2d4f4c\x2dbd4a\x2da2774552fc62.swap’
drwxr-xr-x 2 root root 0 12月 20 00:22 dev-hugepages.mount
drwxr-xr-x 2 root root 0 12月 20 00:22 dev-mqueue.mount
drwxr-xr-x 2 root root 0 12月 20 00:22 dev-vda2.swap
drwxr-xr-x 2 root root 0 12月 20 00:22 dm-event.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 docker.service
drwxr-xr-x 2 root root 0 12月 20 00:22 docker.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 dracut-shutdown.service
drwxr-xr-x 2 root root 0 12月 20 00:22 fail2ban.service
drwxr-xr-x 2 root root 0 12月 20 00:22 firewalld.service
drwxr-xr-x 2 root root 0 12月 20 00:22 import-state.service
drwxr-xr-x 2 root root 0 12月 20 00:22 irqbalance.service
drwxr-xr-x 2 root root 0 12月 20 00:22 kmod-static-nodes.service
drwxr-xr-x 2 root root 0 12月 20 00:22 libstoragemgmt.service
drwxr-xr-x 2 root root 0 12月 20 00:22 lvm2-lvmpolld.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 mcelog.service
-rw-r–r– 1 root root 0 12月 29 00:48 memory.failcnt
–w——- 1 root root 0 12月 29 00:48 memory.force_empty
-rw-r–r– 1 root root 0 12月 29 00:48 memory.kmem.failcnt
-rw-r–r– 1 root root 0 12月 29 00:48 memory.kmem.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:48 memory.kmem.max_usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:48 memory.kmem.slabinfo
-rw-r–r– 1 root root 0 12月 29 00:48 memory.kmem.tcp.failcnt
-rw-r–r– 1 root root 0 12月 29 00:48 memory.kmem.tcp.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:48 memory.kmem.tcp.max_usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:48 memory.kmem.tcp.usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:48 memory.kmem.usage_in_bytes
-rw-r–r– 1 root root 0 12月 20 00:22 memory.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:48 memory.max_usage_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:48 memory.memsw.failcnt
-rw-r–r– 1 root root 0 12月 29 00:48 memory.memsw.limit_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:48 memory.memsw.max_usage_in_bytes
-r–r–r– 1 root root 0 12月 29 00:48 memory.memsw.usage_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:48 memory.move_charge_at_immigrate
-r–r–r– 1 root root 0 12月 29 00:48 memory.numa_stat
-rw-r–r– 1 root root 0 12月 29 00:48 memory.oom_control
———- 1 root root 0 12月 29 00:48 memory.pressure_level
-rw-r–r– 1 root root 0 12月 29 00:48 memory.soft_limit_in_bytes
-r–r–r– 1 root root 0 12月 29 00:48 memory.stat
-rw-r–r– 1 root root 0 12月 29 00:48 memory.swappiness
-r–r–r– 1 root root 0 12月 29 00:48 memory.usage_in_bytes
-rw-r–r– 1 root root 0 12月 29 00:48 memory.use_hierarchy
drwxr-xr-x 2 root root 0 12月 20 00:22 mysqld.service
drwxr-xr-x 2 root root 0 12月 20 00:22 nis-domainname.service
-rw-r–r– 1 root root 0 12月 29 00:48 notify_on_release
drwxr-xr-x 2 root root 0 12月 20 00:22 plymouth-quit-wait.service
drwxr-xr-x 2 root root 0 12月 20 00:22 plymouth-quit.service
drwxr-xr-x 2 root root 0 12月 20 00:22 plymouth-read-write.service
drwxr-xr-x 2 root root 0 12月 20 00:22 plymouth-start.service
drwxr-xr-x 2 root root 0 12月 20 00:22 polkit.service
drwxr-xr-x 2 root root 0 12月 20 00:22 rc-local.service
drwxr-xr-x 2 root root 0 12月 20 00:22 rsyslog.service
drwxr-xr-x 2 root root 0 12月 29 00:41 run-user-0.mount
drwxr-xr-x 2 root root 0 12月 20 00:22 sshd.service
drwxr-xr-x 2 root root 0 12月 20 00:22 sssd-kcm.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 sssd.service
drwxr-xr-x 2 root root 0 12月 20 00:22 sys-fs-fuse-connections.mount
drwxr-xr-x 2 root root 0 12月 20 00:22 sys-kernel-config.mount
drwxr-xr-x 2 root root 0 12月 20 00:22 sys-kernel-debug.mount
drwxr-xr-x 2 root root 0 12月 20 00:22 sys-kernel-tracing.mount
drwxr-xr-x 3 root root 0 12月 20 00:22 system-getty.slice
drwxr-xr-x 2 root root 0 12月 20 00:22 ‘system-sshd\x2dkeygen.slice’
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-coredump.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-fsck-root.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-initctl.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-journal-flush.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-journald-dev-log.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-journald.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-journald.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-logind.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-modules-load.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-random-seed.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-remount-fs.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-sysctl.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-tmpfiles-setup-dev.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-tmpfiles-setup.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-udev-trigger.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-udevd-control.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-udevd-kernel.socket
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-udevd.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-update-utmp.service
drwxr-xr-x 2 root root 0 12月 20 00:22 systemd-user-sessions.service
-rw-r–r– 1 root root 0 12月 29 00:48 tasks
drwxr-xr-x 2 root root 0 12月 20 00:22 tuned.service
drwxr-xr-x 2 root root 0 12月 20 00:22 vdo.service

「docker.service」と「docker.socket」の領域が見受けられます。
dockerについては、こちらの領域の「tasks」に存在します。

[root@mnakamuraAlmaTest ~]# cat /sys/fs/cgroup/memory/system.slice/docker.service/tasks
1075
1118
1119
1120
1121
1137
1144
1248

1075のPIDが見つかりましたね。
なので、memory.limit_in_bytesについても、この領域のものが適用されます。

[root@mnakamuraAlmaTest ~]# cat /sys/fs/cgroup/memory/system.slice/docker.service/memory.limit_in_bytes
9223372036854771712

その他にも、例えば「memory.oom_control」であれば
tasksに記載したPIDのプロセスに纏めてOOM Killerの有効/無効を設定したり…

[root@mnakamuraAlmaTest ~]# cat /sys/fs/cgroup/memory/system.slice/docker.service/memory.oom_control
oom_kill_disable 0
under_oom 0
oom_kill 0

「memory.swappiness」であればswappinessを弄ったり…

[root@mnakamuraAlmaTest ~]# cat /sys/fs/cgroup/memory/system.slice/docker.service/memory.swappiness
60

…と、このように、「tasks」毎に柔軟な設定が可能です。
また、デフォルトで用意されているもの以外でも、
ユーザーが必要に応じてグループ領域や「tasks」を独自で設定し、
プロセス毎に適用する事も可能です。一括管理はcgroupの方が便利そうに見えますね。

因みに、そもそも何故「tasks」が配置されている領域が分かれているか、
気になった方もいらっしゃるかと思いますので、今回例として確認した
docker.service 領域が存在した system.slice 領域について軽く触れておきます。
サーバ内で実行している全てのプロセスは、systemd/initプロセスの子プロセスとなります。
これらは「サービス」「スコープ」「スライス」という3つのユニット単位で、
リソース制御の目的で提供されています。

これらcgroupに関わる階層構造については、下記のようなコマンドで確認可能です。

[root@mnakamuraAlmaTest ~]# LANG=C systemd-cgls
Control group /:
-.slice
|-user.slice
| -user-0.slice | |-session-7.scope | | |-69182 sshd: root [priv] | | |-69196 sshd: root@pts/0 | | |-69197 -bash | | |-69508 systemd-cgls | |-69509 less
| -user@0.service |-init.scope
| |-69187 /usr/lib/systemd/systemd –user
| -69189 (sd-pam) |-init.scope |-1 /usr/lib/systemd/systemd –switched-root –system –deserialize 18
-system.slice |-irqbalance.service |-630 /usr/sbin/irqbalance –foreground
|-fail2ban.service
| -724 /usr/bin/python3.6 -s /usr/bin/fail2ban-server -xf start |-libstoragemgmt.service |-637 /usr/bin/lsmd -d
|-containerd.service
| -741 /usr/bin/containerd |-systemd-udevd.service |-599 /usr/lib/systemd/systemd-udevd
|-docker.service
| -1075 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock |-polkit.service |-642 /usr/lib/polkit-1/polkitd –no-debug
|-chronyd.service
| -649 /usr/sbin/chronyd |-tuned.service |-719 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
|-systemd-journald.service
| -566 /usr/lib/systemd/systemd-journald |-atd.service |-734 /usr/sbin/atd -f
|-sshd.service
| -715 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc -oMACs=hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@op> |-crond.service | |- 735 /usr/sbin/crond -n |-69154 /usr/sbin/anacron -s
|-NetworkManager.service
| -700 /usr/sbin/NetworkManager --no-daemon |-rsyslog.service |-1077 /usr/sbin/rsyslogd -n
|-firewalld.service
| -679 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid |-sssd.service | |-644 /usr/sbin/sssd -i --logger=files | |-676 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files |-680 /usr/libexec/sssd/sssd_nss –uid 0 –gid 0 –logger=files
|-mcelog.service
| -641 /usr/sbin/mcelog --ignorenodev --daemon --foreground |-dbus.service |-635 /usr/bin/dbus-daemon –system –address=systemd: –nofork –nopidfile –systemd-activation –syslog-only
|-mysqld.service
| -813 /usr/libexec/mysqld --basedir=/usr |-system-getty.slice |-getty@tty1.service
| -1096 /sbin/agetty -o -p -- \u --noclear tty1 linux -systemd-logind.service
`-692 /usr/lib/systemd/systemd-logind

詳細は割愛しますが、その中でも「スライス」は階層的に編成されたユニットのグループです。
「スライス」にはプロセスが含まれず、「スコープ」と「サービス」を配置する階層を整理しており、
実際のプロセスは「スコープ」もしくは「サービス」に含まれます。

「サービス」「スコープ」「スライス」はシステム管理者によって手動で作成されるか、
プログラムによって動的に作成されるのですが、「スライス」についてはデフォルトで4つあります。

●-.slice – ルートスライス
●system.slice: すべてのシステムサービスのデフォルトの場所です。
●user.slice – すべてのユーザーセッションのデフォルトの場所。
●machine.slice: すべての仮想マシンおよび Linux コンテナーのデフォルトの場所。

cgroupについては奥深いので、私もまだまだ勉強中です。
因みに cgroup-v1 と cgroup-v2　があったりもするので、
また記事を書く機会がありましたら、次回は実際の設定例をご紹介したいと思います。

それでは、今回はこの辺りで失礼いたします。