【重识云原生】第六章容器6.1.7.4节——cgroups使用

  《重识云原生系列》专题索引：

  1. 第一章——不谋全局不足以谋一域
  2. 第二章计算第1节——计算虚拟化技术总述
  3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
  4. 第二章计算第3节——主流虚拟化技术之Xen
  5. 第二章计算第4节——主流虚拟化技术之KVM
  6. 第二章计算第5节——商用云主机方案
  7. 第二章计算第6节——裸金属方案
  8. 第三章云存储第1节——分布式云存储总述
  9. 第三章云存储第2节——SPDK方案综述
  10. 第三章云存储第3节——Ceph统一存储方案
  11. 第三章云存储第4节——OpenStack Swift 对象存储方案
  12. 第三章云存储第5节——商用分布式云存储方案
  13. 第四章云网络第一节——云网络技术发展简述
  14. 第四章云网络4.2节——相关基础知识准备
  15. 第四章云网络4.3节——重要网络协议
  16. 第四章云网络4.3.1节——路由技术简述
  17. 第四章云网络4.3.2节——VLAN技术
  18. 第四章云网络4.3.3节——RIP协议
  19. 第四章云网络4.3.4节——OSPF协议
  20. 第四章云网络4.3.5节——EIGRP协议
  21. 第四章云网络4.3.6节——IS-IS协议
  22. 第四章云网络4.3.7节——BGP协议
  23. 第四章云网络4.3.7.2节——BGP协议概述
  24. 第四章云网络4.3.7.3节——BGP协议实现原理
  25. 第四章云网络4.3.7.4节——高级特性
  26. 第四章云网络4.3.7.5节——实操
  27. 第四章云网络4.3.7.6节——MP-BGP协议
  28. 第四章云网络4.3.8节——策略路由
  29. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
  30. 第四章云网络4.3.10节——VXLAN技术
  31. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
  32. 第四章云网络4.3.10.3节——VXLAN隧道机制
  33. 第四章云网络4.3.10.4节——VXLAN报文转发过程
  34. 第四章云网络4.3.10.5节——VXlan组网架构
  35. 第四章云网络4.3.10.6节——VXLAN应用部署方案
  36. 第四章云网络4.4节——Spine-Leaf网络架构
  37. 第四章云网络4.5节——大二层网络
  38. 第四章云网络4.6节——Underlay 和 Overlay概念
  39. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
  40. 第四章云网络4.7.2节——virtio网络半虚拟化简介
  41. 第四章云网络4.7.3节——Vhost-net方案
  42. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
  43. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
  44. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
  45. 第四章云网络4.7.8节——SR-IOV方案
  46. 第四章云网络4.7.9节——NFV
  47. 第四章云网络4.8.1节——SDN总述
  48. 第四章云网络4.8.2.1节——OpenFlow概述
  49. 第四章云网络4.8.2.2节——OpenFlow协议详解
  50. 第四章云网络4.8.2.3节——OpenFlow运行机制
  51. 第四章云网络4.8.3.1节——Open vSwitch简介
  52. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
  53. 第四章云网络4.8.4节——OpenStack与SDN的集成
  54. 第四章云网络4.8.5节——OpenDayLight
  55. 第四章云网络4.8.6节——Dragonflow

  56.  第四章云网络4.9.1节——网络卸载加速技术综述

  57. 第四章云网络4.9.2节——传统网络卸载技术

  58. 第四章云网络4.9.3.1节——DPDK技术综述

  59. 第四章云网络4.9.3.2节——DPDK原理详解

  60. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

  61. 第四章云网络4.9.4.2节——智能网卡实现

  62. 第六章容器6.1.1节——容器综述

  63. 第六章容器6.1.2节——容器安装部署

  64. 第六章容器6.1.3节——Docker常用命令

  65. 第六章容器6.1.4节——Docker核心技术LXC

  66. 第六章容器6.1.5节——Docker核心技术Namespace

  67. 第六章容器6.1.6节—— Docker核心技术Chroot

  68. 第六章容器6.1.7.1节——Docker核心技术cgroups综述

  69. 第六章容器6.1.7.2节——cgroups原理剖析

  70. 第六章容器6.1.7.3节——cgroups数据结构剖析

  71. 第六章容器6.1.7.4节——cgroups使用

  72. 第六章容器6.1.8节——Docker核心技术UnionFS

  73. 第六章容器6.1.9节——Docker镜像技术剖析

  74. 第六章容器6.1.10节——DockerFile解析

  75. 第六章容器6.1.11节——docker-compose容器编排

  76. 第六章容器6.1.12节——Docker网络模型设计

  77. 第六章容器6.2.1节——Kubernetes概述

  78. 第六章容器6.2.2节——K8S架构剖析

  79. 第六章容器6.3.1节——K8S核心组件总述

  80. 第六章容器6.3.2节——API Server组件

  81. 第六章容器6.3.3节——Kube-Scheduler使用篇

  82. 第六章容器6.3.4节——etcd组件

  83. 第六章容器6.3.5节——Controller Manager概述

  84. 第六章容器6.3.6节——kubelet组件

  85. 第六章容器6.3.7节——命令行工具kubectl

  86. 第六章容器6.3.8节——kube-proxy

  87. 第六章容器6.4.1节——K8S资源对象总览

  88. 第六章容器6.4.2.1节——pod详解

  89. 第六章容器6.4.2.2节——Pod使用(上)

  90. 第六章容器6.4.2.3节——Pod使用(下)

  91. 第六章容器6.4.3节——ReplicationController

  92. 第六章容器6.4.4节——ReplicaSet组件

  93. 第六章容器基础6.4.5.1节——Deployment概述

  94. 第六章容器基础6.4.5.2节——Deployment配置详细说明

  95. 第六章容器基础6.4.5.3节——Deployment实现原理解析

  96. 第六章容器基础6.4.6节——Daemonset

  97. 第六章容器基础6.4.7节——Job

  98. 第六章容器基础6.4.8节——CronJob

4 CGroups使用

4.1 挂载cgroup树

        开始使用cgroup前需要先挂载cgroup树，下面先看看如何挂载一颗cgroup树，然后再查看其根目录下生成的文件。

#准备需要的目录

  1. #准备需要的目录
  2. dev@ubuntu:~$ mkdir cgroup && cd cgroup
  3. dev@ubuntu:~/cgroup$ mkdir demo
  4.  
  5. #由于name=demo的cgroup树不存在，所以系统会创建一颗新的cgroup树，然后挂载到demo目录
  6. dev@ubuntu:~/cgroup$ sudo mount -t cgroup -o none,name=demo demo ./demo
  7.  
  8. #挂载点所在目录就是这颗cgroup树的root cgroup，在root cgroup下面，系统生成了一些默认文件
  9. dev@ubuntu:~/cgroup$ ls ./demo/
  10. cgroup.clone_children  cgroup.procs  cgroup.sane_behavior  notify_on_release  release_agent  tasks
  11.  
  12. #cgroup.procs里包含系统中的所有进程
  13. dev@ubuntu:~/cgroup$ wc -l ./demo/cgroup.procs
  14. 131 ./demo/cgroup.procs

下面是每个文件的含义：

  • cgroup.clone_children

        这个文件只对cpuset（subsystem）有影响，当该文件的内容为1时，新创建的cgroup将会继承父cgroup的配置，即从父cgroup里面拷贝配置文件来初始化新cgroup，可以参考这里

  • cgroup.procs

        当前cgroup中的所有进程ID，系统不保证ID是顺序排列的，且ID有可能重复

  • cgroup.sane_behavior

        具体功能不详，可以参考这里和这里

  • notify_on_release

        该文件的内容为1时，当cgroup退出时（不再包含任何进程和子cgroup），将调用release_agent里面配置的命令。新cgroup被创建时将默认继承父cgroup的这项配置。

  • release_agent

        里面包含了cgroup退出时将会执行的命令，系统调用该命令时会将相应cgroup的相对路径当作参数传进去。 注意：这个文件只会存在于root cgroup下面，其他cgroup里面不会有这个文件。

  • tasks

        当前cgroup中的所有线程ID，系统不保证ID是顺序排列的，后面在介绍如何往cgroup中添加进程时会介绍cgroup.procs和tasks的差别。

4.2 创建和删除cgroup

        挂载好上面的cgroup树之后，就可以在里面建子cgroup了。

  1. #创建子cgroup很简单，新建一个目录就可以了
  2. dev@ubuntu:~/cgroup$ cd demo
  3. dev@ubuntu:~/cgroup/demo$ sudo mkdir cgroup1
  4.  
  5. #在新创建的cgroup里面，系统默认也生成了一些文件，这些文件的意义和root cgroup里面的一样
  6. dev@ubuntu:~/cgroup/demo$ ls cgroup1/
  7. cgroup.clone_children  cgroup.procs  notify_on_release  tasks
  8.  
  9. #新创建的cgroup里没有任何进程和线程
  10. dev@ubuntu:~/cgroup/demo$ wc -l cgroup1/cgroup.procs
  11. 0 cgroup1/cgroup.procs
  12. dev@ubuntu:~/cgroup/demo$ wc -l cgroup1/tasks
  13. 0 cgroup1/tasks
  14.  
  15. #每个cgroup都可以创建自己的子cgroup，所以我们也可以在cgroup1里面创建子cgroup
  16. dev@ubuntu:~/cgroup/demo$ sudo mkdir cgroup1/cgroup11
  17. dev@ubuntu:~/cgroup/demo$ ls cgroup1/cgroup11
  18. cgroup.clone_children  cgroup.procs  notify_on_release  tasks
  19.  
  20. #删除cgroup也很简单，删除掉相应的目录就可以了
  21. dev@ubuntu:~/cgroup/demo$ sudo rmdir cgroup1/
  22. rmdir: failed to remove 'cgroup1/': Device or resource busy
  23. #这里删除cgroup1失败，是因为它里面包含了子cgroup，所以不能删除，
  24. #如果cgroup1包含有进程或者线程，也会删除失败
  25.  
  26. #先删除cgroup11，再删除cgroup1就可以了
  27. dev@ubuntu:~/cgroup/demo$ sudo rmdir cgroup1/cgroup11/
  28. dev@ubuntu:~/cgroup/demo$ sudo rmdir cgroup1/

4.3 添加进程

        创建新的cgroup后，就可以往里面添加进程了。注意下面几点：

  • 在一颗cgroup树里面，一个进程必须要属于一个cgroup。
  • 新创建的子进程将会自动加入父进程所在的cgroup。
  • 从一个cgroup移动一个进程到另一个cgroup时，只要有目的cgroup的写入权限就可以了，系统不会检查源cgroup里的权限。
  • 用户只能操作属于自己的进程，不能操作其他用户的进程，root账号除外。
  1. #--------------------------第一个shell窗口----------------------
  2. #创建一个新的cgroup
  3. dev@ubuntu:~/cgroup/demo$ sudo mkdir test
  4. dev@ubuntu:~/cgroup/demo$ cd test
  5.  
  6. #将当前bash加入到上面新创建的cgroup中
  7. dev@ubuntu:~/cgroup/demo/test$ echo $$
  8. 1421
  9. dev@ubuntu:~/cgroup/demo/test$ sudo sh -c 'echo 1421 > cgroup.procs'
  10. #注意：一次只能往这个文件中写一个进程ID，如果需要写多个的话，需要多次调用这个命令
  11.  
  12. #--------------------------第二个shell窗口----------------------
  13. #重新打开一个shell窗口，避免第一个shell里面运行的命令影响输出结果
  14. #这时可以看到cgroup.procs里面包含了上面的第一个shell进程
  15. dev@ubuntu:~/cgroup/demo/test$ cat cgroup.procs
  16. 1421
  17.  
  18. #--------------------------第一个shell窗口----------------------
  19. #回到第一个窗口，运行top命令
  20. dev@ubuntu:~/cgroup/demo/test$ top
  21. #这里省略输出内容
  22.  
  23. #--------------------------第二个shell窗口----------------------
  24. #这时再在第二个窗口查看，发现top进程自动和它的父进程（1421）属于同一个cgroup
  25. dev@ubuntu:~/cgroup/demo/test$ cat cgroup.procs
  26. 1421
  27. 16515
  28. dev@ubuntu:~/cgroup/demo/test$ ps -ef|grep top
  29. dev      16515  1421  0 04:02 pts/0    00:00:00 top
  30. dev@ubuntu:~/cgroup/demo/test$
  31.  
  32. #在一颗cgroup树里面，一个进程必须要属于一个cgroup，
  33. #所以我们不能凭空从一个cgroup里面删除一个进程，只能将一个进程从一个cgroup移到另一个cgroup，
  34. #这里我们将1421移动到root cgroup
  35. dev@ubuntu:~/cgroup/demo/test$ sudo sh -c 'echo 1421 > ../cgroup.procs'
  36. dev@ubuntu:~/cgroup/demo/test$ cat cgroup.procs
  37. 16515
  38. #移动1421到另一个cgroup之后，它的子进程不会随着移动
  39.  
  40. #--------------------------第一个shell窗口----------------------
  41. ##回到第一个shell窗口，进行清理工作
  42. #先用ctrl+c退出top命令
  43. dev@ubuntu:~/cgroup/demo/test$ cd ..
  44. #然后删除创建的cgroup
  45. dev@ubuntu:~/cgroup/demo$ sudo rmdir test

4.4 权限

        上面我们都是用sudo(root账号)来操作的，但实际上普通账号也可以操作cgroup

  1. #创建一个新的cgroup，并修改他的owner
  2. dev@ubuntu:~/cgroup/demo$ sudo mkdir permission
  3. dev@ubuntu:~/cgroup/demo$ sudo chown -R dev:dev ./permission/
  4.  
  5. #1421原来属于root cgroup，虽然dev没有root cgroup的权限，但还是可以将1421移动到新的cgroup下，
  6. #说明在移动进程的时候，系统不会检查源cgroup里的权限。
  7. dev@ubuntu:~/cgroup/demo$ echo 1421 > ./permission/cgroup.procs
  8.  
  9. #由于dev没有root cgroup的权限，再把1421移回root cgroup失败
  10. dev@ubuntu:~/cgroup/demo$ echo 1421 > ./cgroup.procs
  11. -bash: ./cgroup.procs: Permission denied
  12.  
  13. #找一个root账号的进程
  14. dev@ubuntu:~/cgroup/demo$ ps -ef|grep /lib/systemd/systemd-logind
  15. root       839     1  0 01:52 ?        00:00:00 /lib/systemd/systemd-logind
  16. #因为该进程属于root，dev没有操作它的权限，所以将该进程加入到permission中失败
  17. dev@ubuntu:~/cgroup/demo$ echo 839 >./permission/cgroup.procs
  18. -bash: echo: write error: Permission denied
  19. #只能由root账号添加
  20. dev@ubuntu:~/cgroup/demo$ sudo sh -c 'echo 839 >./permission/cgroup.procs'
  21.  
  22. #dev还可以在permission下创建子cgroup
  23. dev@ubuntu:~/cgroup/demo$ mkdir permission/c1
  24. dev@ubuntu:~/cgroup/demo$ ls permission/c1
  25. cgroup.clone_children  cgroup.procs  notify_on_release  tasks
  26.  
  27. #清理
  28. dev@ubuntu:~/cgroup/demo$ sudo sh -c 'echo 839 >./cgroup.procs'
  29. dev@ubuntu:~/cgroup/demo$ sudo sh -c 'echo 1421 >./cgroup.procs'
  30. dev@ubuntu:~/cgroup/demo$ rmdir permission/c1
  31. dev@ubuntu:~/cgroup/demo$ sudo rmdir permission

4.5 cgroup.procs vs tasks

        上面提到cgroup.procs包含的是进程ID， 而tasks里面包含的是线程ID，那么他们有什么区别呢？

  1. #创建两个新的cgroup用于演示
  2. dev@ubuntu:~/cgroup/demo$ sudo mkdir c1 c2
  3.  
  4. #为了便于操作，先给root账号设置一个密码，然后切换到root账号
  5. dev@ubuntu:~/cgroup/demo$ sudo passwd root
  6. dev@ubuntu:~/cgroup/demo$ su root
  7. root@ubuntu:/home/dev/cgroup/demo#
  8.  
  9. #系统中找一个有多个线程的进程
  10. root@ubuntu:/home/dev/cgroup/demo# ps -efL|grep /lib/systemd/systemd-timesyncd
  11. systemd+   610     1   610  0    2 01:52 ?        00:00:00 /lib/systemd/systemd-timesyncd
  12. systemd+   610     1   616  0    2 01:52 ?        00:00:00 /lib/systemd/systemd-timesyncd
  13. #进程610有两个线程，分别是610和616
  14.  
  15. #将616加入c1/cgroup.procs
  16. root@ubuntu:/home/dev/cgroup/demo# echo 616 > c1/cgroup.procs
  17. #由于cgroup.procs存放的是进程ID，所以这里看到的是616所属的进程ID（610）
  18. root@ubuntu:/home/dev/cgroup/demo# cat c1/cgroup.procs
  19. 610
  20. #从tasks中的内容可以看出，虽然只往cgroup.procs中加了线程616，
  21. #但系统已经将这个线程所属的进程的所有线程都加入到了tasks中，
  22. #说明现在整个进程的所有线程已经处于c1中了
  23. root@ubuntu:/home/dev/cgroup/demo# cat c1/tasks
  24. 610
  25. 616
  26.  
  27. #将616加入c2/tasks中
  28. root@ubuntu:/home/dev/cgroup/demo# echo 616 > c2/tasks
  29.  
  30. #这时我们看到虽然在c1/cgroup.procs和c2/cgroup.procs里面都有610，
  31. #但c1/tasks和c2/tasks中包含了不同的线程，说明这个进程的两个线程分别属于不同的cgroup
  32. root@ubuntu:/home/dev/cgroup/demo# cat c1/cgroup.procs
  33. 610
  34. root@ubuntu:/home/dev/cgroup/demo# cat c1/tasks
  35. 610
  36. root@ubuntu:/home/dev/cgroup/demo# cat c2/cgroup.procs
  37. 610
  38. root@ubuntu:/home/dev/cgroup/demo# cat c2/tasks
  39. 616
  40. #通过tasks，我们可以实现线程级别的管理，但通常情况下不会这么用，
  41. #并且在cgroup V2以后，将不再支持该功能，只能以进程为单位来配置cgroup
  42.  
  43. #清理
  44. root@ubuntu:/home/dev/cgroup/demo# echo 610 > ./cgroup.procs
  45. root@ubuntu:/home/dev/cgroup/demo# rmdir c1
  46. root@ubuntu:/home/dev/cgroup/demo# rmdir c2
  47. root@ubuntu:/home/dev/cgroup/demo# exit
  48. exit

4.6 release_agent

        当一个cgroup里没有进程也没有子cgroup时，release_agent将被调用来执行cgroup的清理工作。

  1. #创建新的cgroup用于演示
  2. dev@ubuntu:~/cgroup/demo$ sudo mkdir test
  3. #先enable release_agent
  4. dev@ubuntu:~/cgroup/demo$ sudo sh -c 'echo 1 > ./test/notify_on_release'
  5.  
  6. #然后创建一个脚本/home/dev/cgroup/release_demo.sh，
  7. #一般情况下都会利用这个脚本执行一些cgroup的清理工作，但我们这里为了演示简单，仅仅只写了一条日志到指定文件
  8. dev@ubuntu:~/cgroup/demo$ cat > /home/dev/cgroup/release_demo.sh << EOF
  9. #!/bin/bash
  10. echo \$0:\$1 >> /home/dev/release_demo.log
  11. EOF
  12.  
  13. #添加可执行权限
  14. dev@ubuntu:~/cgroup/demo$ chmod +x ../release_demo.sh
  15.  
  16. #将该脚本设置进文件release_agent
  17. dev@ubuntu:~/cgroup/demo$ sudo sh -c 'echo /home/dev/cgroup/release_demo.sh > ./release_agent'
  18. dev@ubuntu:~/cgroup/demo$ cat release_agent
  19. /home/dev/cgroup/release_demo.sh
  20.  
  21. #往test里面添加一个进程，然后再移除，这样就会触发release_demo.sh
  22. dev@ubuntu:~/cgroup/demo$ echo $$
  23. 27597
  24. dev@ubuntu:~/cgroup/demo$ sudo sh -c 'echo 27597 > ./test/cgroup.procs'
  25. dev@ubuntu:~/cgroup/demo$ sudo sh -c 'echo 27597 > ./cgroup.procs'
  26.  
  27. #从日志可以看出，release_agent被触发了，/test是cgroup的相对路径
  28. dev@ubuntu:~/cgroup/demo$ cat /home/dev/release_demo.log
  29. /home/dev/cgroup/release_demo.sh:/test

4.7 如何查看当前进程属于哪些cgroup

        可以通过查看/proc/[pid]/cgroup(since Linux 2.6.24)知道指定进程属于哪些cgroup。

  1. dev@ubuntu:~$ cat /proc/777/cgroup
  2. 11:cpuset:/
  3. 10:freezer:/
  4. 9:memory:/system.slice/cron.service
  5. 8:blkio:/system.slice/cron.service
  6. 7:perf_event:/
  7. 6:net_cls,net_prio:/
  8. 5:devices:/system.slice/cron.service
  9. 4:hugetlb:/
  10. 3:cpu,cpuacct:/system.slice/cron.service
  11. 2:pids:/system.slice/cron.service
  12. 1:name=systemd:/system.slice/cron.service

        每一行包含用冒号隔开的三列，他们的意思分别是

  1. cgroup树的ID， 和/proc/cgroups文件中的ID一一对应。
  2. 和cgroup树绑定的所有subsystem，多个subsystem之间用逗号隔开。这里name=systemd表示没有和任何subsystem绑定，只是给他起了个名字叫systemd。
  3. 进程在cgroup树中的路径，即进程所属的cgroup，这个路径是相对于挂载点的相对路径。

4.8 完整使用示例

        查看cgroup挂载点：

创建隔离组

  1. cd /sys/fs/cgroup/memory/
  2. mkdir test

目录创建完成会自动生成以下文件

ls test

         先写测试程序

  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <string.h>
  4. #include <unistd.h>
  5.  
  6. #define MB (1024 * 1024)
  7.  
  8. int main(int argc, char *argv[])
  9. {
  10.     char *p;
  11.     int i = 0;
  12.     while(1) {
  13.         p = (char *)malloc(MB);
  14.         memset(p, 0, MB);
  15.         printf("%dM memory allocated\n", ++i);
  16.         sleep(1);
  17.     }
  18.  
  19.     return 0;
  20. }

        程序很简单，无限循环，来向系统申请内存，它会每秒消耗1M的内存。

        下面开始写入一些具体的参数：

  • 设置内存限额为5M

sudo sh -c "echo 5M > memory.limit_in_bytes"

  • 把当前bash加入到test中，即所有在此bash下创建的进程都会加入到test中

sudo sh -c "echo $$ >> cgroup.procs"

  • 查看一下oom开关，一般cgroup下oom是不能关闭的。默认为0，即开启。

cat memory.oom_control

  • oom会受到swap空间的影响，设置他为0，把它禁用。

sudo sh -c "echo 0 > memory.swappiness"

        接下来运行测试程序，当分配到5M时，会关闭bash。因为被kill。我们关掉oom，这样程序就会暂停，这时来观察一下。

  1. sudo sh -c "echo 1 >> memory.oom_control"
  2.  
  3. cat memory.oom_control

         运行程序发现停在这里了

         再开终端查看oom，发现under_oom为1，表示当前已经oom了。

         在当前终端设置内存限额为7M。

         回到第一个终端可以看到程序又开始继续分配了，最终停在了5M处

参考链接

彻底搞懂容器技术的基石： cgroup

linux 容器(LXC) 第4章 cgroups_caoshuming_500的博客-CSDN博客

Cgroup原理及使用 - zhrx - 博客园

Linux 基础：cgroup 原理与实现_CGroup_层级_控制

【docker 底层知识】cgroup 原理分析_张忠琳的博客-CSDN博客_cgroup

CGroup的原理和使用_书笑生的博客-CSDN博客_cgroup原理

Docker核心原理之 Cgroup详解

Linux Cgroups详解(二) - lisperl - 博客园

Linux Cgroup系列（04）：限制cgroup的内存使用（subsystem之memory） - SegmentFault 思否

Linux Cgroup系列（01）：Cgroup概述 - SegmentFault 思否

Linux Cgroup系列（02）：创建并管理cgroup - SegmentFault 思否

深入理解 Linux Cgroup 系列（一）：基本概念 - SegmentFault 思否

深入理解 Linux Cgroup 系列（二）：玩转 CPU - SegmentFault 思否

深入理解 Linux Cgroup 系列（三）：内存 - SegmentFault 思否

本文由mdnice多平台发布

posted @ 2023-04-13 22:24  Kevin_jun  阅读(63)  评论(0)    收藏  举报