我们希望通过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表示没有限制。