cgroup测试存储设备IOPS分配

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.

cgroup测试存储设备IOPS分配_第1张图片

随着包括存储设备在内服务器的能力越来越高,特别是用上了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模块的可靠性,收集数据作为应用的参考。

祝玩得开心!

你可能感兴趣的:(group)