知道了故障原因，修复起来就简单了，防止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。
echo "2" >/proc/sys/vm/overcommit_memory
当时的情况就设置为0是欠考虑的，更稳妥的做法是应当参考历史数据。
而且设置为0确实在内存不足的时候更容易触发oom-killer，这里我们还是恢复默认值：
echo "60" >/proc/sys/vm/swappiness
这次的优化过程犯了非常非常多的错误。大致总结下如下：
不要一次优化多个配置，更不能多个人分别取优化配置！
做修改哪怕只是一行的时候同样要记得备份
不要想当然的去优化内核参数，例如swappiness等重要参数
多看日志，勤看messages
其实大部分都是耳熟能详的东西，太阳底下无新事，但就是老生长谈的东西依旧要时刻
牢记在心，一句话对线上要有敬畏之心。