如何控制oom-killer

知道了故障原因，修复起来就简单了，防止oom-killer 被我的zabbix server下手呗。

oom-killer 触发的原因都是内存不足导致的，而内存不足通常是由于内存超分配导致的。

关于linux内核的超分配是由overcommit_memory参数控制的(/proc/sys/vm/overcommit_memory)，

关于参数的解释大神都有很详细的解释了，我就直接拿来用了:

• 0：启发式策略，比较严重的Overcommit将不能得逞，比如你突然申请了128TB的内存。

  而轻微的Overcommit将被允许。另外，root能Overcommit的值比普通用户要稍微多些。

• 1：永远允许Overcommit，这种策略适合那些不能承受内存分配失败的应用，比如某些科学计算应用。

• 2：永远禁止Overcommit，在这个情况下，系统所能分配的内存不会超过swap+RAM*系数

  （/proc/sys/vm/overcmmit_ratio，默认50%，你可以调整）， 如果这么多资源

  已经用光，那么后面任何尝试申请内存的行为都会返回错误，这通常意味着此时没法运行任何新程序。

由于默认设置是0，所以导致了我的zabbix server一开始是可以轻微的超额申请到所需的

内存的，但当运行到一段时间之后系统就会因为严重缺乏内存到触发oom-killer。

杜绝内存超分配

如果没有内存超分配的问题，那系统永远都只会分配可分配的内存，即系统永远不会严重缺乏内存，
自然也不会触发oom-killer。

恢复默认的swappiness

echo "2" >/proc/sys/vm/overcommit_memory

当时的情况就设置为0是欠考虑的，更稳妥的做法是应当参考历史数据。

而且设置为0确实在内存不足的时候更容易触发oom-killer，这里我们还是恢复默认值：

echo "60" >/proc/sys/vm/swappiness

经验教训

这次的优化过程犯了非常非常多的错误。大致总结下如下：

• 不要一次优化多个配置，更不能多个人分别取优化配置！

• 做修改哪怕只是一行的时候同样要记得备份

• 不要想当然的去优化内核参数，例如swappiness等重要参数

• 多看日志，勤看messages

其实大部分都是耳熟能详的东西，太阳底下无新事，但就是老生长谈的东西依旧要时刻

牢记在心，一句话对线上要有敬畏之心。

参考

• 理解和配置 Linux 下的 OOM Killer
• Linux内核OOM机制的详细分析

本文固定链接: https://www.fulingjiang.cn/linux/90.html