/proc/sys/vm/overcommit_memory中的数值(0,1,2)决定了你malloc时采用不同的策略.
0: 表示采用试探性的内存分配,此时会消除明显的malloc错误.比方说你物理内存是512
M,没有交换分区,当你要malloc大于512M的内存时就不会成功.这是默认的情况.
1: 表示不采用任何防范措施.此时你只要malloc小于3GB的内存都会成功的. 这是早期的
linux采用的默认情况,我记得2.4内核默认就使用这个.
2: 表示采用比较严格的限制.根据当时物理内存的剩余量和交换分区的大小决定进程最
大可以malloc多少内存.
baidu结果
实际测试：
overcommit_memory ==2 ，物理内存使用完后，打开任意一个程序均显示“内存不足”；
overcommit_memory ==1，会从buffer中释放较多物理内存，适合大型科学应用软件，但oom-killer机制仍然起作用；
overcommit_memory ==0，系统默认设置，释放物理内存较少，使得oom-killer机制运作很明显。
Linux的内存管理有一套机制：当系统内存溢出的时候，它会选择一个/几个适当的进程杀掉以维持系统的稳定运行。不过机器毕竟是机器，虽然它竭尽全力去选择那些真正是罪魁祸首的进程，但是难免会出错，或者是不公平，到头来系统还是因为误杀而变得残缺不全，甚至不能这场运行。这个时候可能就需要：人为地干预、引导系统做出正确的选择。
这种行为的控制是通过调整进程相应目录下的/proc/[PID]/oom_adj来实现的，其中oom_adj的取值返回是-17~15，当进程的oom_adj是-17时，系统将不会杀死它，-16到15使得进程的/proc/[PID]/oom_score值呈指数（K * 2 ^ n）形式递增，也就是说他们被杀的可能性呈指数形式递增。另外，开天辟地的第一个进程（进程号为1）init也不在被杀之列，无论它的oom_adj值为多少。原来只有系统资源管理权限（CAP_SYS_RESOURCE）的进程才能做oom_adj值的调整，现在如果是把进程的被杀可能性提高则不需要什么特殊权限，我们也确实不应剥夺它自杀或者是它的拥有者有意把它推上悬崖的权利。
禁止进程被杀的具体操作为：
xiaosuo # pgrep dbus-daemon
4595
6664
xiaosuo # cat /proc/4595/oom_score
559
xiaosuo # echo -17 > /proc/4595/oom_adj
xiaosuo # cat /proc/4595/oom_score
0
注意：这个技巧是比较危险的，除非你能100%肯定你禁止被杀的进程没有问题，不然不要尝试做愚蠢的设定，否则后果自负。
Tip: OOM Killer 的关闭与激活方式：
# echo "0" > /proc/sys/vm/oom-kill
# echo "1" > /proc/sys/vm/oom-kill
