1 使用：创建树并且attach子系统
- 首先要创建文件系统的挂载点作为树的根
mkdir /cgroup/name
mkdir /cgroup/cpu_and_mem
- Mount这个挂载点到一个或者多个子系统
mount -t cgroup -o subsystems name /cgroup/name
mount -t cgroup -o cpu,cpuset,memory cpu_and_mem /cgroup/cpu_and_mem
- 这个时候查看子系统
~]# lssubsys -am
cpu,cpuset,memory /cgroup/cpu_and_mem
net_cls
ns
cpuacct
devices
freezer
blkio
- 重新mount
mount -t cgroup -o remount,cpu,cpuset,cpuacct,memory cpu_and_mem /cgroup/cpu_and_mem
- 查看子系统
~]# lssubsys -am
cpu,cpuacct,cpuset,memory /cgroup/cpu_and_mem
net_cls
ns
devices
freezer
blkio
- 创建子group: mkdir /cgroup/hierarchy/name/child_name
- mkdir /cgroup/cpuset/lab1/group1
使用：Process Behavior in the Root Control Group
对于blkio和cpu子系统来说，在root cgroup下的进程和在子cgroup下的进程，对资源的分配不同
例如有一个root cgroup，文件夹为/rootgroup，有两个子cgroup，/rootgroup/red/ and /rootgroup/blue/
在这三个cgroup下面都创建cpu.shares，并且值设为1 如果在三个cgroup下面各创建一个进程，则每个进程CPU占有率为三分之一
然而当子cgroup里面添加更多的进程，则整个子cgroup还是占有三分之一的CPU
如果在root cgroup里面再创建两个进程，则变成了按照进程数来分，也即每个进程五分之一
所以在使用blkio和cpu的时候，尽量使用子cgroup
子系统：blkio
子系统控制并监控cgroup中的任务对块设备的I/O访问。
blkio.weight
指定cgroup默认可用访问块I/O的相对比例(加权)，范围在100到1000
blkio.weight_device
指定对cgroup中可用的具体设备I/O访问的相对比例(加权)，范围是100到 1000。
blkio.throttle.read_bps_device
the upper limit on the number of read operations a device can perform. Entries have three fields: major, minor, and bytes_per_second.
blkio.throttle.write_bps_device
the upper limit on the number of write operations a device can perform.
随着包括存储设备在内服务器的能力越来越高，特别是用上了PCIe存储卡后，IOPS能力通常有10几万，马上过剩。在这种情况下，一台服务器可以干很多事情，在上面跑很多服务。那么如何保证系统的服务质量是个很重要的事情了。
我们在下来的的项目中倾向于用cgroup来做资源的隔离和限制，原因是cgroup的开销很小，而且很易用。cgroup 可以参考这里
我们特别关心cgroup的blkio子模块，他有2种限制模式:
1. throttle，限制每个进程能使用的IOPS或者吞吐量。
2. weight，现在每个进程能使用的IOPS的能力的比例，必须通过CFQ调度器来实现。
文档和具体的参数可以看上面提到的cgroup文档。
要使用blkio的weight限制需要注意几个事情：
1. 必须走directio, 如果buffered io因为最终写IO的进程不是发起IO的进程，结果会有很大的偏差。
2. 调度器必须是CFQ。
3. 测试工具必须支持cgroup的相关限制。
4. 最好是随机的IO。
这里只是粗粗演示下如何用fio按照比例来限制进程使用的IO, 我们来构造下场景：
我们在创建2个1g大小的文件，进行随机的混合读写，一个给500的比例，一个给100的比例，总的比例是1000。那么理论上可以看到A进程可以得到多于B进程5倍的IO能力。
操作如下：
$ cat test.fio [global] bs=4k ioengine=libaio iodepth=32 direct=1 rw=randrw rwmixread=90 time_based runtime=180 cgroup_nodelete=1 [test1] filename=test1.dat size=1G cgroup_weight=500 cgroup=test1 [test2] filename=test2.dat size=1G cgroup_weight=100 cgroup=test2 $ cat /sys/block/sda/queue/scheduler noop deadline [cfq] $ sudo fio test.fio test1: (g=0): rw=randrw, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32 test2: (g=0): rw=randrw, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32 fio 2.0 Starting 2 processes Jobs: 2 (f=2): [mm] [5.5% done] [618K/90K /s] [151 /22 iops] [eta 02m:51s] ...
我们从另外一个终端可以看到IO能力的分配情况：
$ sudo lssubsys -am cpuset net_cls perf_event cpu /sys/fs/cgroup/cpu cpuacct /sys/fs/cgroup/cpuacct memory /sys/fs/cgroup/memory devices /sys/fs/cgroup/devices freezer /sys/fs/cgroup/freezer blkio /sys/fs/cgroup/blkio $ pgrep -x fio 3837 3839 3840 $ cat /sys/fs/cgroup/blkio/test1/tasks 3839 $ cat /sys/fs/cgroup/blkio/test2/tasks 3840 $ sudo iotop
差不多是5:1的比例，符合预期。
我们在使用的时候会担心kernel的稳定性，所以用fio能够大压力，长时间的来测试cgroup模块的可靠性，收集数据作为应用的参考。
祝玩得开心！
