基本介绍
CGroups 是一种对进程资源管理和控制的统一框架，它提供的是一种机制，而具体的策略（Policy）是通过子系统（subsystem）来完成的。子系统是CGroups对进程组进行资源控制的具体行为。
机制和策略是Linux操作系统中一种经典的设计思想，所谓机制就是“我要提供哪种功能”，而策略则是“我要怎样来实现这种功能”。
RHEL提供了9个CGroups子系统。CGroups中每个子系统都代表一种类型的资源，详见子系统。
在RHEL6中有Namespaces，在RHEL7中，通过lssubsys未列出。Namespaces 命名空间子系统。
在RHEL7中增了 perf_event, hugetlb 两个子系统。
安装
#yum install libcgroup-tools.x86_64 0:0.41-8.el7
专有名词：
层级 - hierarchies：
配置文件
/etc/cgconfig.conf libcgroup的缺省配置文件 default libcgroup configuration file
/etc/cgconfig.d/ libcgroup的缺省配置目录 default libcgroup configuration files directory
/etc/cgrules.conf
/etc/cgsnapshot_blacklist.conf
/etc/sysconfig/cgred
命令工具
/usr/bin/cgclassify
/usr/bin/cgcreate 创建CGroup群组
/usr/bin/cgdelete 删除CGroup群组
/usr/bin/cgexec
/usr/bin/cgget
/usr/bin/cgset
/usr/bin/cgsnapshot
/usr/bin/lscgroup
/usr/bin/lssubsys
/usr/sbin/cgclear
/usr/sbin/cgconfigparser
/usr/sbin/cgrulesengd
服务
/usr/lib/systemd/system/cgconfig.service 提供创建层级的简单方法，并在层级中附加子系统，且在那些层级中管理CGroups。根据配置文件/etc/cgconfig.conf 的内容，可创建层级、挂载所需文件系统、创建CGroups及为每个组群设定子系统参数。
/usr/lib/systemd/system/cgred.service
配置文件
1.1. /etc/cgconfig.conf
描述 DESCRIPTION
libcgroup配置文件，定义控制组(control groups)、他们的参数及挂载点。文件由mount、group、default三个sections组成。这些section可以构成层级，所有的都是可选的。以#开始的行都是注释行。
为每个子系统创建并挂载独立层级，并在这些层级中附加子系统。停止cgconfig服务，则会卸载它挂载的所有层级。文件包括两个主要类型的条目：mount 和 group。挂载条目生成并挂载层级，将其作为虚拟文件系统，同时将子系统附加到那些层级中。挂载(mount)条目使用以下语法定义：
mount section:
mount {
<controller> = <path>;
...
}
controller 内核子系统(kernel subsystem)的名字。内核支持的子系统列表在/proc/cgroups文件中；
| subsys_name | hierarchy | num_cgroups | enabled |
| cpuset | 10 | 1 | 1 |
| cpu | 4 | 1 | 1 |
| cpuacct | 4 | 1 | 1 |
| memory | 3 | 1 | 1 |
| devices | 2 | 1 | 1 |
| freezer | 5 | 1 | 1 |
| net_cls | 7 | 1 | 1 |
| blkio | 8 | 1 | 1 |
| perf_event | 6 | 1 | 1 |
| hugetlb | 9 | 1 | 1 |
命名的层次结构(named hierarchy)可以被作为contoller "name=<somename>", controller的名字需要用双引号（double quotes). 详见 Sample 2
libcgroup可以合并所有的子系统挂载到同一个目录，，被挂载的目录仅仅被挂载一次。详见Sample 1
Path 被挂载的目录，此目录用于给定地控制器(controller)关联组层次结构(group hierarchy)。此目录在cgconfig服务启动的时候如果不存在，将被cgconfig服务自动创建，cgconfig服务停止的时候，被删除。
mount section 如果没有，即没有控制器(controller)被挂载。
group section:
group <name> {
[permissions]
<controller> {
<param name> = <param value>;
...
}
...
}
name: 控制组(control group)的名字，只能是字符，允许是路径名。这些组形成一个树，如，一个控制组中包含零个或多个子组(subgroups), 子组能用'/'做分隔符。
根控制组(root control group)在所有的层次结构中一直自动被创建，它是组层级结构(group hierarchy)的基础。可以在cgconfig.conf文件中，显示的以'.'作为根控制组的名字。这个 可以用作设置它的权限，详见 Sample 6.
当一个子组没有指定父组的时候，父组被自动创建。
permissions: 在被挂载的文件系统(mounted filesystem)中，给定控制组的权限。root对控制组可以作任何事情。权限的语法如下：
perm {
task {
uid = <task user>;
gid = <task group>;
fperm = <file permissions>
}
admin {
uid = <admin name>;
gid = <admin group>;
dperm = <directory permissions>
fperm = <file permissions>
}
}
task user/group 用户和组的名字， 他们拥有控制组的任务文件(tasks file). 给定的fperm指定文件权限。需要注意的是，fperm设置的值不使用作为指定权限。相反，当前文件的所有者权限被用作"umask" 组用户和其他用户权限。例如，如果fperm=777, 那么group用户和others用户与文件所有者的权限相同。
task user/group Name of the user and the group, which own the tasks file of the control group. Given fperm then specify the file permissions. Please note that the given value is not used as was specified. Instead, current file owner permissions are used as a "umask" for group and others permissions. For example if fperm = 777 then both group and others will get the same permissions as the file owner.
admin user/group 用户和用户组的名字，他们拥有控制组的其余文件。给定的fperm和dperm控制文件和路径的权限。同样，fperm和dperm给定的值，用于masked当前文件/路径所有者的权限。dperm为路径，fperm为文件。
admin user/group Name of the user and the group which own the rest of control group's files. Given fperm and dperm control file and directory permissions. Again, the given value is masked by the file/directory owner permissions.
权限仅仅被应用到圈定的控制组，且不被子组继承。在控制组定义中，如果没有perm部分，root:root是所有文件的拥有者，同样，如果fperm和dperm没有设置，缺省文件的权限被保留。
Permissions are only apply to the enclosing control group and are not inherited by subgroups. If there is no perm section in the control group definition, root:root is the owner of all files and default file permissions are preserved if fperm resp. dperm are not specified.
controller 内核子系统(the kernel subsystem)的名字。这部分可以为空，在这个情况下缺省的内核参数将被用。通过指定控制器(controller)，控制组和它所有的父级被特定的子系统。一个控制组能被多个子系统控制，即使子系统被挂载不同的目录。一个控制组必须至少被一个子系统控制，因此libcgroup知道在哪个层级中创建控制组。
Name of the kernel subsystem. The section can be empty, default kernel parameters will be used in this case. By specifying controller the control group and all its parents are controlled by the specific subsystem. One control group can be controlled by multiple subsystems, even if the subsystems are mounted on different directories. Each control group must be controlled by at least one subsystem, so that libcgroup knows in which hierarchies the control group should be created.
给定的控制器的参数可以在后面的方括号部分被修改。
The parameters of the given controller can be modified in the following section enclosed in brackets.
param name 设置的文件名称。每个控制器可以有零个或多个参数。
Name of the file to set. Each controller can have zero or more parameters.
param value 当控制被创建的时候，值被写到文件中。如果有空格和其他特殊字符，此值应用双引号引起来。
Value which should be written to the file when the control group is created. If it is enclosed in double quotes `"', it can contain spaces and other special characters.
如果没有group部分设定，没有group被创建。
If no group section is specified, no groups are created.
default section has this form:
default {
perm {
task {
uid = <task user>;
gid = <task group>;
fperm = <file permissions>
}
admin {
uid = <admin name>;
gid = <admin group>;
dperm = <directory permissions>
fperm = <file permissions>
}
}
}
perm部分的内容与group部分中的形式相同。这里定义的权限指定了所有者，组用户和所有组用户文件的权限，这个没有明确在组部分制定他们的权限。即没有在组部分设定权限，这里的设置才有效。
Content of the perm section has the same form as in group section. The permissions defined here specify owner and permissions of groups and files of all groups, which do not have explicitly specified their permissions in their group section.
template section 与组部分有相同的结构。模板名用相同的模板字符串作为cgrules.conf 定义的tag(参考 cgrules.conf). 模板定义被用作控制组定义规则在cgrules.conf用相同的定义名。模板不用default部分设置。即缺省部分的设置对模板部分没有作用。
template section has the same structure as group section. Template name uses the same templates string as cgrules.conf destination tag (see (cgrules.conf (5)). Template definition is used as a control group definition for rules in cgrules.conf (5) with the same destination name. Templates does not use default section settings.
/etc/cgconfig.d/ 目录被用来保存附加的配置文件。cgrulesengds 搜索这个目录为附件的模板。
/etc/cgconfig.d/ directory can be used for additional configuration files. cgrulesengd searches this directory for additional templates.
命令： cgconfigparser
服务： cgconfig
关系，服务cgconfig启动命令cgconfigparse，命令使用配置文件cgconfig.conf(缺省的配置文件)
Examples:
Example 1
The configuration file:
mount {
cpu = /mnt/cgroups/cpu;
cpuacct = /mnt/cgroups/cpu;
}
creates the hierarchy controlled by two subsystems with no groups inside. It corresponds to the following operations:
mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
修改/etc/cgconfig.conf, 添加 mount {}后，重新启动cgconfig(#service cgconfig restart)失败，查看(#service cgconfig status)权限错误：
11月 16 19:45:09 localhost.localdomain cgconfigparser[3403]: Error: cannot mount cpu,cpuacct to /mnt/cgroups/cpu: Permission denied
Example 2
The configuration file:
mount {
cpu = /mnt/cgroups/cpu;
"name=scheduler" = /mnt/cgroups/cpu;
"name=noctrl" = /mnt/cgroups/noctrl;
}
group daemons {
cpu {
cpu.shares = "";
}
}
group test {
"name=noctrl" {
}
}
创建两个层次结构。一个层次结构命名为scheduler，控制cpu子系统，在组守护进行内部。另一个命名为noctrl层级结构，不带任何控制器，带有test组。相应的操作如下：
creates two hierarchies. One hierarchy named scheduler controlled by cpu subsystem, with group daemons inside. Second hierarchy is named noctrl without any controller, with group test. It corresponds to following operations:
#mkdir /mnt/cgroups/cpu
#mount -t cgroup -o cpu,name=scheduler cpu /mnt/cgroups/cpu
#mount -t cgroup -o none,name=noctrl none /mnt/cgroups/noctrl #mkdir /mnt/cgroups/cpu/daemons
#echo > /mnt/cgroups/cpu/daemons/www/cpu.shares #mkdir /mnt/cgroups/noctrl/tests
守护进行组(daemons group)在它的第一个子组(subgroup)被创建的时候，自动被创建。它的所有参数有缺省值，仅仅root才能访问组的文件。
由于cpuacct和cpu子系统都被挂载到相同目录，所有组也被cpuacct隐式控制，即使在任何组中没有cpuacct部分。
The daemons group is created automatically when its first subgroup is created. All its parameters have the default value and only root can access group's files.
Since both cpuacct and cpu subsystems are mounted to the same directory, all groups are implicitly controlled also by cpuacct subsystem, even if there is no cpuacct section in any of the groups.
Example 3
The configuration file:
mount {
cpu = /mnt/cgroups/cpu;
cpuacct = /mnt/cgroups/cpu;
}
group daemons/www {
perm {
task {
uid = root;
gid = webmaster;
fperm = ;
}
admin {
uid = root;
gid = root;
dperm = ;
fperm = ;
}
}
cpu {
cpu.shares = "";
}
}
group daemons/ftp {
perm {
task {
uid = root;
gid = ftpmaster;
fperm = ;
}
admin {
uid = root;
gid = root;
dperm = ;
fperm = ;
}
}
cpu {
cpu.shares = "";
}
}
创建了由两个子系统控制的层级，内带一个组和两个子组，设置了一个参数。相应如下操作(除了文件权限的小技巧模仿通过通过修改文件权限):
creates the hierarchy controlled by two subsystems with one group and two subgroups inside, setting one parameter. It corresponds to the following operations (except for file permissions which are little bit trickier to emulate via chmod):
mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu mkdir /mnt/cgroups/cpu/daemons mkdir /mnt/cgroups/cpu/daemons/www
chown root:root /mnt/cgroups/cpu/daemons/www/*
chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks
echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares # + chmod the files so the result looks like:
# ls -la /mnt/cgroups/cpu/daemons/www/
# admin.dperm = 755:
# drwxr-xr-x. 2 root webmaster 0 Jun 16 11:51 .
#
# admin.fperm = 744:
# --w-------. 1 root webmaster 0 Jun 16 11:51 cgroup.event_control
# -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cgroup.procs
# -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.stat
# -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.usage
# -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.usage_percpu
# -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.rt_period_us
# -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.rt_runtime_us
# -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.shares
# -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 notify_on_release
#
# tasks.fperm = 770
# -rw-rw----. 1 root webmaster 0 Jun 16 11:51 tasks mkdir /mnt/cgroups/cpu/daemons/ftp
chown root:root /mnt/cgroups/cpu/daemons/ftp/*
chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks
echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares # + chmod the files so the result looks like:
# ls -la /mnt/cgroups/cpu/daemons/ftp/
# admin.dperm = 755:
# drwxr-xr-x. 2 root ftpmaster 0 Jun 16 11:51 .
#
# admin.fperm = 700:
# --w-------. 1 root ftpmaster 0 Jun 16 11:51 cgroup.event_control
# -r--------. 1 root ftpmaster 0 Jun 16 11:51 cgroup.procs
# -r--------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.stat
# -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.usage
# -r--------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.usage_percpu
# -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.rt_period_us
# -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.rt_runtime_us
# -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.shares
# -rw-------. 1 root ftpmaster 0 Jun 16 11:51 notify_on_release
#
# tasks.fperm = 774:
# -rw-rw-r--. 1 root ftpmaster 0 Jun 16 11:51 tasks
守护进行组(daemons group)在它的第一个子组(subgroup)被创建的时候，自动被创建。它的所有参数有缺省值，仅仅root才能访问组的文件。
由于cpuacct和cpu子系统都被挂载到相同目录，所有组也被cpuacct隐式控制，即使在任何组中没有cpuacct部分。
The daemons group is created automatically when its first subgroup is created. All its parameters have the default value and only root can access the group's files.
Since both cpuacct and cpu subsystems are mounted to the same directory, all groups are implicitly also controlled by the cpuacct subsystem, even if there is no cpuacct section in any of the groups.
Example 4
The configuration file:
mount {
cpu = /mnt/cgroups/cpu;
cpuacct = /mnt/cgroups/cpuacct;
}
group daemons {
cpuacct{
}
cpu {
}
}
创建两个层级，一个普通组包括两个层级。对应如下操作：
creates two hierarchies and one common group in both of them. It corresponds to the following operations:
mkdir /mnt/cgroups/cpu
mkdir /mnt/cgroups/cpuacct
mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct mkdir /mnt/cgroups/cpu/daemons
mkdir /mnt/cgroups/cpuacct/daemons
实际上创建了两个组。一个组在 cpuacct 层级, 另一个组在 cpu 层级。这两个组通常没有任何东西，能够包括不同的子组和不同的任务。
In fact there are two groups created. One in the cpuacct hierarchy, the second in the cpu hierarchy. These two groups have nothing in common and can contain different subgroups and different tasks.
Example 5
The configuration file:
mount {
cpu = /mnt/cgroups/cpu;
cpuacct = /mnt/cgroups/cpuacct;
}
group daemons {
cpuacct{
}
}
group daemons/www {
cpu {
cpu.shares = "";
}
}
group daemons/ftp {
cpu {
cpu.shares = "";
}
}
创建两个层级，内部包括几个组。每个组被创建在两个层级中。对应的操作如下：
creates two hierarchies with few groups inside. One of the groups is created in both hierarchies. It corresponds to the following operations:
mkdir /mnt/cgroups/cpu
mkdir /mnt/cgroups/cpuacct
mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct mkdir /mnt/cgroups/cpuacct/daemons
mkdir /mnt/cgroups/cpu/daemons
8 mkdir /mnt/cgroups/cpu/daemons/www
echo > /mnt/cgroups/cpu/daemons/www/cpu.shares
mkdir /mnt/cgroups/cpu/daemons/ftp
echo > /mnt/cgroups/cpu/daemons/ftp/cpu.shares
组守护进程被创建在两个层级。 在 cpuacct 层级，配置文件中显示定义组。在 cpu 层级中，当 www 被创建时，组被隐式创建。这两个组通常没有任何东西，如他们没有共享进程和子组。 组 www 和 ftp 被创建仅仅在 cpu 层级，不被 cpuacct 子系统控制。
Group daemons is created in both hierarchies. In the cpuacct hierarchy the group is explicitly mentioned in the configuration file. In the cpu hierarchy the group is created implicitly when www is created there. These two groups have nothing in common, for example they do not share processes and subgroups. Groups www and ftp are created only in the cpu hierarchy and are not controlled by the cpuacct subsystem.
Example 6
The configuration file:
mount {
cpu = /mnt/cgroups/cpu;
cpuacct = /mnt/cgroups/cpu;
}
group . {
perm {
task {
uid = root;
gid = operator;
}
admin {
uid = root;
gid = operator;
}
16 }
cpu {
}
}
group daemons {
perm {
task {
uid = root;
gid = daemonmaster;
}
admin {
uid = root;
gid = operator;
}
}
cpu {
}
}
创建了被两个子系统控制、带有一个组的层级，在组中明确了一下权限。相应的操作如下：
creates the hierarchy controlled by two subsystems with one group having some special permissions. It corresponds to the following operations:
mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu chown root:operator /mnt/cgroups/cpu/*
chown root:operator /mnt/cgroups/cpu/tasks mkdir /mnt/cgroups/cpu/daemons
chown root:operator /mnt/cgroups/cpu/daemons/*
chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks
操作组(operator group)中的用户被允许去管理这些控制组(control groups), 例如，没有root权限，创建新的控制组和在组中移动进程。
daemonmaster 组的成员能够移动进程到 daemons 进程组，但不能从组中移出进程。仅仅 operator 或 root 能够做。
Users which are members of the operator group are allowed to administer the control groups, i.e. create new control groups and move processes between these groups without having root privileges.
Members of the daemonmaster group can move processes to the daemons control group, but they can not move the process out of the group. Only the operator or root can do that.
Example 7
The configuration file:
mount {
cpu = /mnt/cgroups/cpu;
cpuacct = /mnt/cgroups/cpuacct;
}
group students {
cpuacct{
}
cpu {
}
}
template students/%u {
cpuacct{
}
cpu {
}
}
#mkdir /mnt/cgroups/cpu/daemons
#mkdir /mnt/cgroups/cpuacct/daemons
这个情况与Example 4相似。唯一不同是模板，模板用于作为一个目标，如果一些规则适用"/students/%u".
The situation is the similar as in Example 4. The only difference is template, which is used if some rule uses "/students/%u" as a destination.
注意 RECOMMENDATIONS
保持层级独立 Keep hierarchies separated
存在多个层级是非常有效和能在各种场景使用。保持事情的清楚，不要在多个层级中创建一个组。Exampls 4 和 5 显得不宜阅读和可能有点混淆，特别其他人阅读配置文件时。
Having multiple hierarchies is perfectly valid and can be useful in various scenarios. To keeps things clean, do not create one group in multiple hierarchies. Examples 4 and 5 show how unreadable and confusing it can be, especially when reading somebody elses configuration file.
显式好于隐式 Explicit is better than implicit
libcgroup 能够隐式创建组，组为可配置子组的创建需要（即libcgroup在创建子组时，隐式创建组）。在简单场景下，这可能是有用的和节省一下键盘敲击。当出现多个层级是，最好是显示的明确多个组和关于他们的所有控制区。
libcgroup can implicitly create groups which are needed for the creation of configured subgroups. This may be useful and save some typing in simple scenarios. When it comes to multiple hierarchies, it's better to explicitly specify all groups and all controllers related to them.
FILES
/etc/cgconfig.conf
default libcgroup configuration file
/etc/cgconfig.d/
default libcgroup configuration files directory
SEE ALSO
cgconfigparser (8)
BUGS
参数值必须要不带空格的单一字符串。不支持带引号的字符串。
Parameter values must be single strings without spaces. Parsing of quoted strings is not implemented.
使用 #man cgconfig.conf 获取更多信息。
子系统
#lssubsys 列出当前的子系统 list hierarchies containing given subsystem
[root@localhost ~]# lssubsys
cpuset : 对于多核cpu，该子系统可以设置进程组只能在指定的核上运行，并且还可以设置进程组在制定的内存节点上申请内存。
cpu,cpuacct : CPU子系统为每个进程组设置一个使用CPU的权重值，以此管理进程组对CPU的访问。cpuacct子系统只用于生成当前进程组内的进程对CPU的使用报告。
memory : 该子系统提供了以页面为单位对内存的访问，比如对进程组设置内存使用上限等，同时可以生成内存资源报告。
devices : 该子系统可以限制进程组对设备的访问，即允许或禁止进程组对某设备的访问。
freezer : 该子系统可以使得进程组中的所有进程挂起。
net_cls : 该子系统提供对网络带宽的访问限制，比如对发送带宽和接收带宽进程限制。
blkio : 该子系统用于限制每个块设备的输入/输出。与cpu子系统类似，该子系统通过为每个进程组设置权重来控制块设备对其的I/O时间；其次，该子系统也可以限制进程组的I/O带宽及IOPS。
perf_event
hugetlb
显示子系统mount目录
[root@localhost ~]# lssubsys -aim
cpuset /sys/fs/cgroup/cpuset
cpu,cpuacct /sys/fs/cgroup/cpu,cpuacct
memory /sys/fs/cgroup/memory
devices /sys/fs/cgroup/devices
freezer /sys/fs/cgroup/freezer
net_cls /sys/fs/cgroup/net_cls
blkio /sys/fs/cgroup/blkio
perf_event /sys/fs/cgroup/perf_event
hugetlb /sys/fs/cgroup/hugetlb
相关指令：
lscgroup (1), cgcreate (1), cgdelete
lscgroup list all cgroups
[root@localhost ~]# lscgroup
devices:/
memory:/
cpu,cpuacct:/
freezer:/
perf_event:/
net_cls:/
blkio:/
hugetlb:/
cpuset:/
相关指令： lssubsys (1), cgcreate (1), cgdelete (1), cgconfig.conf (5)
cgcreate 创建CGroup群组
/usr/bin/cgcreate
EXAMPLES
cgcreate -g *:student -g devices:teacher
在所有的挂载层级创建 student 控制组，在包含devices控制器的层级
create control group student in all mounted hierarchies and create control group teacher in hierarchy containing controller devices.
使用CGroups
1.查找某个进程所属CGroups
#ps -O cgroups
[root@localhost ~]# ps -o cgroup
CGROUP
:name=systemd:/user.slice/user-.slice/session-.scope
:name=systemd:/user.slice/user-.slice/session-.scope
FAQ：
1. 子系统是否可以创建、删除.