cgroup内存限制不起作用的原因

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

情景还原

在memory.limit_in_bytes中设置如下：

可见，虽然设置了cgroup，而且看起来似乎是生效了，但实际上并没有限制住。

问题排查

因为该程序的资源限制是利用agent代理程序去做的，并非人为去操作，所以一开始怀疑该进程没有加入cgroup资源限制策略，查看之后排除了这一可能性。
第一步查到进程PID以及其相应的线程ID，如下所示：

问题解决

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

$ echo 0 >  memory.swappiness

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

所以，将oom_kill_disable设置为1后重启程序，该问题得以解决。

总结

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

参考资料：docker cgroup 技术之memory（首篇）