cgroup & oom-killer 简介

2019/08/08 18:02
阅读数 226

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机制分析

内存不足触发Linux OOM-killer机制分析

linux下OOM问题排查

这里我们说一下一个常见的误区,就是有人会认为触发了oom-killer的进程就是问题的罪魁祸首,比如我们这个例子中的这个nginx进程。其实日志中invoke oom-killer的这个进程有时候可能只是一个受害者,因为其他应用/进程已将系统内存用尽,而这个invoke oomkiller的进程恰好在此时发起了一个分配内存的请求而已。在系统内存已经不足的情况下,任何一个内存请求都可能触发oom killer的启动。
展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部