Docker之Cgroup与接口的使用（二）子系统详解

cpuset子系统

为一组指定的进程分配指定的cpu和内存节点。在NUMA架构的服务器上，通常将进程与指定的cpu和内存节点绑定来达到，提升性能。（具体是怎么提升的有待学习）。
在这里只介绍主要的2个接口，其余的有时间可以进行深入了解
1. cpuset.cpus：允许进程使用的cpu列表
2. cpuset.mems：允许进行使用的内存节点列表（cpu还是理解的但是内存节点？？？？和内存寻址有关系吗？？）

姑且还是看一下cpuset的接口（控制文件）
[root@VM_116_112_centos child]# ls
cgroup.clone_children cpuset.cpu_exclusive cpuset.mem_hardwall cpuset.memory_spread_page cpuset.sched_load_balance tasks
cgroup.event_control cpuset.cpus cpuset.memory_migrate cpuset.memory_spread_slab cpuset.sched_relax_domain_level
cgroup.procs cpuset.mem_exclusive cpuset.memory_pressure cpuset.mems notify_on_release

cpu子系统

用于限制进行的cpu占用比率。
1. cpu比重分配：cpu.shares。举个例子
cd /sys/fs/cgroup/cpu
mkdir test1创建cgroup test1
mkdir test2创建cgroup test2
cd test1
echo 1024 > cpu.shares
cd test2
echo 512 > cpu.shares
设置完毕后当test1和test2中的进程争抢cpu资源时，test1中将获得比test2中多一倍的cpu占用比率，这只有当争抢cpu时才有效。
2. cpu带宽限制：cpu.cfs_period_us和cpu.cfs_quota_us接口（控制文件），单位是微秒。举个例子，我将test1中的period设为1000000（1秒），quota设为500000（0.5秒），那么test1中的进程在1秒内最多只能运行0.5秒,然后被强制睡眠，直到下一个1秒才能继续运行。。
3. 实时进程的cpu带宽限制：之前的两个接口只能用于普通进程。cpu.rt_period_us和cpu.rt_runtime_us,用法与上述类似。
看一下cpu中的所有接口。
ls
cgroup.clone_children cgroup.procs cpuacct.usage cpu.cfs_period_us cpu.rt_period_us cpu.shares notify_on_release
cgroup.event_control cpuacct.stat cpuacct.usage_percpu cpu.cfs_quota_us cpu.rt_runtime_us cpu.stat tasks

cpuacct子系统

用来统计各个cgroup的cpu使用情况
1. cpuacct.stat：查看这个cgroup在内核态和用户态消耗的cpu时间。单位是USER_HZ（0.01秒）
如：
cat cpuacct.stat
user 3819849
system 3496899
2. cpuacct.usage：报告这个cgroup消耗的总的cpu时间，单位纳秒。如：
[root@VM_116_112_centos cpuacct]# cat cpuacct.usage
84608407349362
3. cpuacct.usage_percpu：顾名思义是这个cgroup在每个cpu上消耗的时间，总和是cpuacct.usage。
其余接口
cgroup.clone_children cgroup.sane_behavior cpuacct.usage_percpu cpu.rt_period_us cpu.stat release_agent test1
cgroup.event_control cpuacct.stat cpu.cfs_period_us cpu.rt_runtime_us docker system.slice test2
cgroup.procs cpuacct.usage cpu.cfs_quota_us cpu.shares notify_on_release tasks user.slice
在这里可以看到一个现象，我在cpu中创建的test1 cgroup在cpuacct中也能看见。
原因是：
ls -l
总用量 0
drwxr-xr-x 5 root root 0 7月 30 08:43 blkio
lrwxrwxrwx 1 root root 11 7月 30 08:43 cpu -> cpu,cpuacct
lrwxrwxrwx 1 root root 11 7月 30 08:43 cpuacct -> cpu,cpuacct
drwxr-xr-x 7 root root 0 7月 30 08:43 cpu,cpuacct
cpu和cpuacct都是cpu,cpuacct的软连接，所以在cpu中创建的cgroup在cpuacct中也可以看见，其实从功能方面想的话，也应该是这样的，你要统计各个cgroup占用cpu使用情况，你就得了解所有占用过cpu的cgroup对象。
既然这样，其余接口是和cpu是一样的就不再重复列出。

memory子系统

用来限制cgroup的内存上限。
1. memory.limit_in_bytes：设置内存上限，单位字节，也可以使用k/K，m/M，g/G，例如echo 1G > memory.limit_in_bytes默认情况下，如果cgroup使用的内存超过上限，内核会尝试回收内存，如果仍无法将内存控制在限制以内，系统会触发OOM（它会在系统内存耗尽的情况下，启用自己算法有选择性的kill 掉一些进程），选择并杀死cgroup中的某个进程。
2. memory.memsw.limit_in_bytes：设置内存加上交换分区的总量，通过设置这个值，可以防止进程将交换分区用完。
3. memory.oom_control：如果设置为0，则内存使用超过限制，系统不会触发OOM，kill进程，而是阻塞进程直到有内存被释放可供使用时；另一方，系统会向用户态发送事件通知，用户态的监控程序可以根据该事件来做相应的处理，比如提高内存的上限。
4. memory.stat：汇报内存使用情况
查看其余接口
[root@VM_116_112_centos memory]# ls
cgroup.clone_children memory.kmem.limit_in_bytes memory.limit_in_bytes memory.oom_control release_agent
cgroup.event_control memory.kmem.max_usage_in_bytes memory.max_usage_in_bytes memory.pressure_level system.slice
cgroup.procs memory.kmem.slabinfo memory.memsw.failcnt memory.soft_limit_in_bytes tasks
cgroup.sane_behavior memory.kmem.tcp.failcnt memory.memsw.limit_in_bytes memory.stat user.slice
docker memory.kmem.tcp.limit_in_bytes memory.memsw.max_usage_in_bytes memory.swappiness
memory.failcnt memory.kmem.tcp.max_usage_in_bytes memory.memsw.usage_in_bytes memory.usage_in_bytes
memory.force_empty memory.kmem.tcp.usage_in_bytes memory.move_charge_at_immigrate memory.use_hierarchy
memory.kmem.failcnt memory.kmem.usage_in_bytes memory.numa_stat notify_on_release

blkio子系统

用来限制cgroup的blockIO带宽。
1. blkio.weight：设置权重值，范围在100~1000之间，和cpu.shares类似是比重分配，不是绝对带宽的限制，只有多个cgroup竞争同一个块设备的带宽才会起作用
2. blkio.weight_device：设置具体设备权重值，设置了这个值，上面的blkio.weight会被覆盖。
3. blkio.throttle.read_bps_device：对具体设备，设置每秒读磁盘的带宽上限。
4. blkio.throttle.write_bps_device：写上限
5. blkio.throttle.read_iops_device：IOPS（每秒进行读写操作的次数），读上限
6. blkio.throttle.write_iops_device：写上限
其余接口
[root@VM_116_112_centos blkio]# ls
blkio.io_merged blkio.io_serviced_recursive blkio.reset_stats blkio.throttle.write_bps_device cgroup.event_control tasks
blkio.io_merged_recursive blkio.io_service_time blkio.sectors blkio.throttle.write_iops_device cgroup.procs user.slice
blkio.io_queued blkio.io_service_time_recursive blkio.sectors_recursive blkio.time cgroup.sane_behavior
blkio.io_queued_recursive blkio.io_wait_time blkio.throttle.io_service_bytes blkio.time_recursive docker
blkio.io_service_bytes blkio.io_wait_time_recursive blkio.throttle.io_serviced blkio.weight notify_on_release
blkio.io_service_bytes_recursive blkio.leaf_weight blkio.throttle.read_bps_device blkio.weight_device release_agent
blkio.io_serviced blkio.leaf_weight_device blkio.throttle.read_iops_device cgroup.clone_children system.slice

device子系统

控制cgroup中的进程对哪些设备有访问权限。
1. devices.list：只读文件，显示目前可以被访问的设备列表。
[root@VM_116_112_centos devices]# cat devices.list
a *:* rwm
每一行都分为3部分：

1. 类型：可以是a，b，c，分别代表所有设备，块设备和字符设备
2. 设备号：格式major:minor
3. 权限：rwm，分别表示可读，可写，可创建设备节点

2. devices.allow：
3. devices.deny：
[root@VM_116_112_centos devices]# ls devices.allow devices.deny -l
–w——- 1 root root 0 7月 30 08:43 devices.allow
–w——- 1 root root 0 7月 30 08:43 devices.deny
[root@VM_116_112_centos devices]# ls devices.list -l
-r–r–r– 1 root root 0 7月 30 08:43 devices.list
从命令输出结果来看，devices.list是只读文件，devices.allow和devices.deny是只写文件，那么向这两个只写文件中写入上述格式的内容可以允许或禁止相应设备的访问。
（好好思考一下这样做的好处？？？？？对于同一块内容，通过只写和只读的作用是？？？）

PS：剩余的子系统等用到的时候再进行进一步的学习。