今天遇到一个cgroup资源限制时,内存限制不起作用的问题。一开始,对进程的cgroup设置最大内存限制为10M,但运行了几分钟以后,内存明显飙上去了,甚至达到了20多M。

情景还原

memory.limit_in_bytes中设置如下:
image.png
10485760表示的是字节数,也就是等于 1024 * 1024 * 10 = 10M
运行一段时间后,查看实际使用的内存,memory.usage_in_bytes文件中数值如下:
image.png
可以看到,确实拿捏得死死的,看起来似乎内存限制成功了,没有什么问题。
可是当使用top命令去查看的时候,却发现已经内存消耗已高达23M左右,这明显不正常。
image.png
使用前台监控界面查看,得到的是同样的结果:
image.png
可见,虽然设置了cgroup,而且看起来似乎是生效了,但实际上并没有限制住。

问题排查

因为该程序的资源限制是利用agent代理程序去做的,并非人为去操作,所以一开始怀疑该进程没有加入cgroup资源限制策略,查看之后排除了这一可能性。
第一步查到进程PID以及其相应的线程ID,如下所示:
image.png
然后查看tasks里面加入的进程号,如下:
image.png
可以看到,该进程所有的进程和线程号都被加入到了cgroup中。因此,并不是这个引起的。
然后就想到会不会是使用了swap内存,可以看到,8G的swap内存已经被使用了24M,看起来有点像。
image.png
为了验证这一猜想,我把进程先给停掉了,然后查看swap内存使用情况:
image.png
可以看到,flow进程停掉之后,swap内存一下子从24M降到了20K,看样子就是这个东西搞的鬼。
于是我查看了一下memory.swappiness,这个数值居然达到了30,看来是这个问题没跑了。
image.png

问题解决

知道了问题所在,解决也就比较简单了。首先第一步,把memory.swappiness设为0

$ echo 0 >  memory.swappiness

然后重新启动进程,这次成功了,当内存刚刚达到10M,直接就被kill掉了。
但实际上,我并不希望这个进程就如此简单粗暴的被杀掉,考虑到memory.oom_control可以设置内存达到限制后的处理措施,oom_kill_disable0代表内存超过限制就杀掉进程,oom_kill_disable1则代表继续等待,当有内存释放时,继续申请内存。总而言之,就是不会把进程杀掉。
image.png
所以,将oom_kill_disable设置为1后重启程序,该问题得以解决。

总结

cgroupLinux系统内核提供的一种资源限制的策略,使用起来十分方便。鼎鼎大名的Docker容器就是基于此技术,平时工作中对这种技术缺乏钻研和积累,只知道简单的使用,并没有深入研究每个参数到底代表什么,其内部原理又是什么,所以才有了遇到这种问题耗时耗力的情况。
比如memory.swappiness中从数值代表什么意思,为啥设置为0之后cgroup就起作用了?原来的30又代表什么?
通过查资料后,了解到memory.swappiness中的数值其实并不是确切的数值,而是代表了进程使用swap空间的一个权重,该数值范围从0-100100表示积极使用swap0表示优先使用内存。

参考资料:docker cgroup 技术之memory(首篇)


禹鼎侯
176 声望466 粉丝

OLAP数据库开发。跨平台数据采集。