OOM-killer 线上设置 +vm +OOM机制

http://blog.csdn.net/tenfyguo/article/details/9409743

http://blog.csdn.net/tenfyguo/article/details/50185915

http://blog.chinaunix.net/uid-20788636-id-4308527.html

http://www.furion.info/649.html

Linux下有3种Overcommit的策略（参考内核文档：vm/overcommit-accounting），可以在/proc/sys/vm/overcommit_memory配置（取0,1和2三个值，默认是0）。
（）：启发式策略，比较严重的Overcommit将不能得逞，比如你突然申请了128TB的内存。而轻微的overcommit将被允许。另外，root能Overcommit的值比普通用户要稍微多
（）1：永远允许overcommit，这种策略适合那些不能承受内存分配失败的应用，比如某些科学计算应用。
（）2:永远禁止overcommit，在这个情况下，系统所能分配的内存不会超过swap+RAM*系数（/proc/sys/vm/overcmmit_ratio，默认50%，你可以调整），如果这么多资源已经用光，那么后面任何尝试申请内存的行为都会返回错误，这通常意味着此时没法运行任何新程序。
/proc/sys/vm # cat overcommit_ratio

当然我可以修改proc//oom_adj的值，这里的默认值为0，当我们设置为-17时，对于该进程来说，就不会触发OOM机制，被杀掉。
echo - > /proc/$(pidof sshd)/oom_adj
这里为什么是-17呢？这和Linux的实现有关系。在Linux内核中的oom.h文件中，可以看到下面的定义：
/* /proc//oom_adj set to -17 protects from the oom-killer */
#define OOM_DISABLE (-17)
/* inclusive */
#define OOM_ADJUST_MIN (-16)
#define OOM_ADJUST_MAX 15
这个oom_adj中的变量的范围为15到-16之间。越大越容易被kill。oom_score就是它计算出来的一个值，就是根据这个值来选择哪些进程被kill掉的。
总之，通过上面的分析可知，满足下面的条件后，就是启动OOM机制。
) VM里面分配不出更多的page（注意linux kernel是延迟分配page策略，及用到的时候才alloc；所以malloc + memset才有效）。
) 用户地址空间不足，这种情况在32bit机器上及user space超过了3GB，在64bit机器上不太可能发生。
     当该机制被触发后，会让什么样的进程退出？
只要存在overcommit，就可能会有OOM killer。 Linux系统的选择策略也一直在不断的演化。我们可以通过设置一些值来影响OOM killer做出决策。Linux下每个进程都有个OOM权重，在/proc//oom_adj里面，取值是-17到+15，取值越高，越容易被干掉。  最终OOM killer是通过/proc//oom_score这个值来决定哪个进程被干掉的。这个值是系统综合进程的内存消耗量、CPU时间(utime + stime)、存活时间(uptime - start time)和oom_adj计算出的，消耗内存越多分越高，存活时间越长分越低。总之，总的策略是：损失最少的工作，释放最大的内存同时不伤及无辜的用了很大内存的进程，并且杀掉的进程数尽量少。  另外，Linux在计算进程的内存消耗的时候，会将子进程所耗内存的一半同时算到父进程中。