cgroup & oom-killer 简介
cgroup内存限制
memory.failcnt
memory.limit_in_bytes
memory.usage_in_bytes
memory.max_usage_in_bytes
memory.memsw.failcnt
memory.memsw.limit_in_bytes
memory.memsw.max_usage_in_bytes
memory.memsw.usage_in_bytes
memory.soft_limit_in_bytes
memory.oom_control
memory.use_hierarchy
memory.swappiness
memory.stat
带 memsw 的表示虚拟内存，不带 memsw 的仅包括物理内存。其中，limit_in_bytes 是用来限制内存使用的，其他的则是统计报告。
memory.memsw.limit_in_bytes：内存＋swap空间使用的总量限制。
memory.limit_in_bytes：内存使用量限制。
memory.memsw.limit_in_bytes 必须大于或等于 memory.limit_in_byte。
要解除内存限制，把对应的值设为 -1 即可。
这种方式限制进程内存占用会有个风险。当进程试图占用的内存超过限制时，会触发 oom ，导致进程直接被杀，从而造成可用性问题。即使关闭控制组的 oom killer，在内存不足时，进程虽然不会被杀，但是会长时间进入 D 状态（等待系统调用的不可中断休眠），并被放到 OOM-waitqueue 等待队列中， 仍然导致服务不可用。因此，用 memory.limit_in_bytes 或 memory.memsw.limit_in_bytes 限制进程内存占用仅应当作为一个保险，避免在进程异常时耗尽系统资源。如，预期一组进程最多会消耗 1G 内存，那么可以设置为 1.5G 。这样在发生内存泄露等异常情况时，可以避免造成更严重问题。
memory.oom_control：内存超限之后的 oom 行为控制。
关闭oom killer：
设置 oom_kill_disable 为 1。（0 为开启）
oom-killer机制分析
这里我们说一下一个常见的误区，就是有人会认为触发了oom-killer的进程就是问题的罪魁祸首，比如我们这个例子中的这个nginx进程。其实日志中invoke oom-killer的这个进程有时候可能只是一个受害者，因为其他应用／进程已将系统内存用尽，而这个invoke oomkiller的进程恰好在此时发起了一个分配内存的请求而已。在系统内存已经不足的情况下，任何一个内存请求都可能触发oom killer的启动。
