Chinaunix

标题: 关于Linux系统上cGroup的使用的一点疑问？ [打印本页]

作者: kifast 时间: 2012-11-13 10:58
标题: 关于Linux系统上cGroup的使用的一点疑问？
我现在使用cGroup去对一个进程的资源进行控制，

1.如果进程起来后，再将pid加入到task文件中，结果是资源不受控；
2.如果把shell的pid先加入task中，然后在这个shell中启动要受控的进程，结果就可以达到资源受控的效果。

望有对cGroup机制了解的同学，帮忙解答一下我的疑惑。

作者: darrenlee3 时间: 2012-11-13 12:48
manual失败？
试试 libcgroup包里的cgexec/cgclassify

作者: kifast 时间: 2012-11-13 14:25
回复 2# darrenlee3

1.用过cgclassify，这个命令是在进程起来后将pid加入task，调整资源控制参数，会不生效；
2.至于cgexec，这个到是可以生效，但是这个就相当于进程启动前就把握了主动权；

如果不能对一个现存的进程进行资源控制，那么cgclassify的存在是为了什么呢？

作者: darrenlee3 时间: 2012-11-13 14:41

kifast 发表于 2012-11-13 14:25
回复 2# darrenlee3

1.用过cgclassify，这个命令是在进程起来后将pid加入task，调整资源控制参数，会不 ...

我没太明白你的意思，cgroup就是predefine一些控制组，然后把进程加到适合的组里，已组为单位进行资源控制，并不是以进程为单位进行控制，肯定是先有某控制组和该组的控制参数，然后才有需要加入该组的进程

A control group is a collection of processes that are bound by the same criteria. These groups can be hierarchical, where each group inherits limits from its parent group. The kernel provides access to multiple controllers (subsystems) through the cgroup interface.

作者: kifast 时间: 2012-11-13 14:50
回复 4# darrenlee3

你说的没错，就是有了控制组，然后再将进程加入控制组，我现在只讨论只加入一个要控制的进程的情况，当然就是控制一个进程了。

主要就是加入的时机问题，能用cgexec加入一个尚未启动的，可以达到控制的效果；

但用cgclassify加入一个已经启动的进程，控制组对这个之前就已经启动的进程，无法达到通过调整参数控制资源。

谢谢你的耐心回复。

作者: darrenlee3 时间: 2012-11-13 16:18
本帖最后由 darrenlee3 于 2012-11-13 16:19 编辑

kifast 发表于 2012-11-13 14:50
回复 4# darrenlee3

可以达到效果，cgroup是立刻生效的
写个循环计算的是cpu 100%的程序或者内存泄漏的程序可以测出来

你是怎么测的？怎么算“生效”？

以cpu 100%的程序来说，在2核cpu上，程序启动2次产生2个进程，无论怎么设置cpu.shares，他们总是100%的占用率，一个进程占一个cpu
但如果此时再启动2个进程，cpu.shares就会生效，效果是按比例分配cpu带宽，cpu占用率也会和share值成比例。

作者: kifast 时间: 2012-11-13 20:56
回复 6# darrenlee3

嗯，你说的没错，对于CPU的限制，我知道为什么了，

主要是因为多线程程序，在Linux中，会吧进程中的线程也当作一个进程来处理，

当占用CPU资源的不是主线程时，将这个程序的PID加入tasks中，其实是没有限制那个真正耗CPU的线程的。

解决办法：将已经启动的进程的PID放入cgroup.procs中，cgroup会自动将其所有线程放入tasks中。

不过，对于内存的限制，我目前还不知道是什么原因导致，对一个已经起来的进程，为什么无法限制住物理内存的占用。

作者: kifast 时间: 2012-11-13 22:05
回复 6# darrenlee3

ok，memory子系统的task migration，已经知道为什么不行了。

在内存控制的时候，

当一个进程起来时，默认会放到memory子系统的根目录中的tasks文件中，

对于将一个task从根目录group中迁移到另外一个自己定义的group时，默认的情况是，其charge并没有顺带一起带走。

此时，就需要把目标group中的memory.move_charge_at_immigrate置为1。从而开启内存控制子系统的task迁移特性。

作者: 0young70 时间: 2014-07-01 10:44
回复 7# kifast

我遇到了跟楼主一样的问题，按照楼主的研究解决了，谢谢。呵呵

作者: q1208c 时间: 2014-07-01 16:23
虽然不是太明白, 但看上去好高级的样子.

不知道楼主这样做的目的是什么? 是否可以使用虚拟机来解决呢?

那样的话, 是不是会更简单些呢?

作者: kifast 时间: 2014-07-01 22:58
本帖最后由 kifast 于 2014-07-01 23:00 编辑

回复 10# q1208c

虽然不是太明白, 但看上去好高级的样子.
不知道楼主这样做的目的是什么? 是否可以使用虚拟机来解决呢?
那样的话, 是不是会更简单些呢?

这样搞，主要是通过cGroup来限制主机上的虚拟机的CPU资源和内存资源的使用。cGroup主要是针对Linux上的进程进行分组化管理，一个虚拟机其实也是主机上的一个进程而已。

作者: q1208c 时间: 2014-07-02 07:37
回复 11# kifast

据我所知, 每一种虚拟机都有自己的资源管理机制. 可以控制虚拟机的资源使用.

我的意思是, 如果每台机器上都有这么指定, 一两台还好, 要是很多机器的话, 估计管理员累shi了.

作者: kifast 时间: 2014-07-03 00:14
回复 12# q1208c

其实实现的是类似Vmware Esxi上虚拟机资源池的功能。KVM虚拟机没有什么自己的资源管理功能，你给它两个vcpu，guest机系统忙起来，host机就会占满2个host机上的cpu核的资源，一个vcpu对应一个host机线程。

作者: q1208c 时间: 2014-07-03 08:18
回复 13# kifast

这个我知道. 不过, 通常的做法跟你的正相反.

使用虚拟机的人, 没人想要性能下降, 都想性能最大化. 所以, 在虚拟机部署上,
一般是总的 vcpu 数量不大于总的物理 cpu 数量, 这样才能最大化的利用系统
资源.

不过, 如果你有兴趣, 可以研究一下 LXC, 那是个基于容器的虚拟机, 好象就是用的 cGroup 的功能. 具体我没研究过.

作者: kifast 时间: 2014-07-03 09:19
回复 14# q1208c

Vmware对单个虚拟机的vcpu个数的建议是1到2个，超配反而会引发性能下降，白皮书是这么说的。我们考虑单个物理机上存在若干虚拟机，不同虚拟机划分不同的资源组，不同资源组按cGroup来划分资源配额，
在产生资源竞争的时候，按实现划分的份额比例来分配。

作者: q1208c 时间: 2014-07-03 09:21
回复 15# kifast

我觉得 vmware 那说明怕是针对 Windows 的. 因为多数 Windows OS 根本就不支持更多的 CPU.

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)