http://www.vpsee.com/2013/10/how-to-configure-the-linux-oom-killer/
http://www.cnblogs.com/itfriend/archive/2011/12/14/2287160.html
其他可选的临时解决方法：
关闭oom-killer
echo "0" > /proc/sys/vm/oom-kill
vi /etc/sysctl.conf
vm.oom-kill = 0
2. 清空cache （可选）
echo 1 > /proc/sys/vm/drop_caches
之前做游戏时遇到一次 OOM killer。细节有些忘记了。和这个差不过。就保存下来了。、
转自 http://www.kuqin.com/linux/20120701/321430.html
受害人口述悲惨的遭遇——
1、最近一段时间（更换了预发机器后）我负责的一个应用的预发环境(线上稳定得像个婴儿~)特别不稳定，最先是应用频频的过几天就发现提供的接口不工作了，但容器Jetty还在跑得欢，于是jstack/jmap看，发现没有一个线程在跑我的war包中的程序，但是容器里个中间件的sar还跑得很欢(-_-|||)，dump出来的对象也没有一点蛛丝马迹，所有日志到04:03就什么也没有了。然后查发现一个中间件的sar(远程接口层)包刚好在那个时候升级了，这玩意用OSGI的CloassLoader来加载整个应用，自然就怀疑它怎么着把我的Class都卸载掉了。简单，回滚到前一版本试试。
2、诡异的第二天还是4:03分，又发作了!排除了新sar的原因，就百思不和其解了，发现-XX:+CMSClassUnloadingEnabled开着，关掉。第二天还是一样！各种看代码都没有问题，在一个无穷循环的线程里打日志，各种招都用上还是老样子，连Servlet消失了，突然对哥掌握的Java知识产生了莫名其妙的怀疑…
3、这个应用改过名字，上边2个应用的目录都存在的。发现老目录的log文件修改时间居然是当前时间,再PS一看，发现启的进程是老应用的！新老2个war变化非常大，之前验证的点在老war里都木有的，好，觉得终于找着原因了。删老目录，找PE查脚本，果然查到启老应用的脚本!停掉脚本。甚至把老的应用目录link到新应用，即使脚本改不干净也不致于把我应用杀掉，免受接口调用方骚扰啊。
4、奇迹再一次发生了。应用在4:03准时消失了，老的确实也不起来了。
因为是预发环境，线上完全无问题，怀疑是环境问题所以也就一直没花太多时间去查。PE也觉不再有脚本在跑了，好吧，决定好好查一下。
首先，看系统日志，希望能找到SSH登录日志、命令执行日志或进程启动/终止日志，搜4点这个时间，wtmp/secure都没有发现。
然后，找messages这个时间点，找到：
Jun 20 04:05:14 ***.pre.cm3 kernel: : java invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Jun 20 04:05:14 ***.pre.cm3 kernel: :
Jun 20 04:05:14 ***.pre.cm3 kernel: : Call Trace:
Jun 20 04:05:14 ***.pre.cm3 kernel: : [] out_of_memory+0x8b/0x203
...
Jun 20 04:05:18 ***.pre.cm3 kernel: : Mem-info:
...
oom-killer，之前不知道有这个东西，想想JVM自己不可能发生OOM,因为即没OOM日志也没Crash Core日志，而且还每次都是同一时间点！应用中也木有这种定时任务。
关于Linux OOM-killer机制——
linux oom-killer是一种自我保护机制，当系统分配不出内存时(触发条件)会触发这个机制，由操作系统在己有进程中挑选一个占用内存较多，回收内存收益最大的进程kill掉来释放内存。
系统为每个进程做评估(/proc/<pid>/oom_score中数值最大的进程被kill掉)，参考这里。
前面的问题，Java进程占用内存足够多，进程生存又比较短，正是OOM-killer的首选啊，所以中招。
- /**
- * badness – calculate a numeric value for how bad this task has been
- * @p: task struct of which task we should calculate
- * @uptime: current uptime in seconds
- *
- * The formula used is relatively simple and documented inline in the
- * function. The main rationale is that we want to select a good task
- * to kill when we run out of memory.
- *
- * Good in this context means that:
- * 1) we lose the minimum amount of work done
- * 2) we recover a large amount of memory
- * 3) we don’t kill anything innocent of eating tons of memory
- * 4) we want to kill the minimum amount of processes (one)
- * 5) we try to kill the process the user expects us to kill, this
- * algorithm has been meticulously tuned to meet the principle
- * of least surprise … (be careful when you change it)
- */
另外，Linux的malloc分配内存，也不是一次到位的真分配了指定大小的物理内存(Overcommit机制,另一篇也不错,这里Fenny一篇)，而是先承诺你，实际用到的时候才去系统分配，如果刚好那个时候内存不够了，就会触发oom-killer。
Linux下有3种Overcommit的策略（参考内核文档：vm/overcommit-accounting），可以在/proc/sys/vm/overcommit_memory配置。取0,1和2三个值，默认是0。
0：启发式策略，比较严重的Overcommit将不能得逞，比如你突然申请了128TB的内存。而轻微的Overcommit将被允许。另外，root能Overcommit的值比普通用户要稍微多些。
1：永远允许Overcommit，这种策略适合那些不能承受内存分配失败的应用，比如某些科学计算应用。
2：永远禁止Overcommit，在这个情况下，系统所能分配的内存不会超过swap+RAM*系数（/proc/sys/vm/overcmmit_ratio，默认50%，你可以调整），如果这么多资源已经用光，那么后面任何尝试申请内存的行为都会返回错误，这通常意味着此时没法运行任何新程序。
我的机器为什么会触发OOM-killer——
先查了下sar的日志：
- 12:00:01 AM CPU %user %nice %system %iowait %steal %idle
- 04:00:01 AM all 0.01 0.00 0.00 0.00 0.01 99.98
- 04:10:02 AM all 0.55 0.00 20.71 37.97 0.06 40.71
- 04:20:01 AM all 0.01 0.00 0.04 0.24 0.01 99.71
system cpu占的比较多，应该是kernel OOM-killer执行所占掉的。再看没有启java进程情况下这个时间点的日志，CPU是正常的。
cat /proc/sys/vm/overcommit_memory 值0，即启发式策略，允许Overcommit。
再看这台机器上比较消耗内存的进程：
总可用内存才2G（更换机器之前为4G，后面的配置是按4G来配的）,JVM就申请了2G+，再加上nginx所占申请内存，远超实际物理内存2G+Swap 1G范围了，应用之所以正常是应用启动不久，实际用的内存并没用那么多，到晚上达到临界值，其实一个不相干的定时任务申请内存，刚好就触发了OOM-killer了。
nginx和java应用线上长时间验证是稳定的，不存在内存泄露，至于机器上4:03启动了什么任务，其实都不那么重要了。
参考资料：
How the Linux OOM killer works
Linux 的 Out-of-Memory (OOM) Killer
相关推荐
OOM Killer，全称为Out of Memory Killer，是Linux内核中的一种机制，用于处理系统内存不足的情况。当系统内存耗尽时，为了避免整个系统的崩溃，OOM Killer会选择并终止一些进程来释放内存，从而确保系统的稳定运行...
Linux系统的OOM Killer处理机制 Linux系统的OOM（Out of Memory）Killer处理机制是一种内核机制，用于在系统内存不足时杀掉某个进程以腾出内存留给系统用，不致于让系统立刻崩溃。OOM Killer的触发条件是系统内存...
在Linux系统中，当内存资源紧张，即将耗尽时，为避免系统崩溃，Linux内核引入了一种称为OOM (Out Of Memory) Killer的机制。OOM Killer会选择性地杀死某些进程以回收内存。这一机制主要针对系统可用内存（包括Swap...
当Linux系统面临内存不足的压力时，内核会启动一个称为“Out-of-Memory (OOM) Killer”的机制来防止系统崩溃。然而，OOM Killer可能会选择终止重要的进程，包括Erlang应用程序。针对这种情况，有一个名为“heart_oom...
《理解Linux OOM Killer机制：从lab8_oom实验入手》 Linux操作系统的OOM (Out-Of-Memory) Killer是一个重要的内存管理机制，用于处理系统内存不足的情况。当系统资源极度紧张，无法分配新的内存时，OOM Killer会...
在Linux系统中，当系统内存不足时，OOM killer会被触发，它会选择并终止某些进程以回收内存，从而防止系统完全崩溃。描述提到的“oom_adj”是Linux内核中的一个参数，用于调整进程的OOM分数。将其设置为-17意味着这...
在这种情况下，Linux内核会启动oom-killer机制来杀死消耗内存最多的进程，以保护系统的稳定性。针对这个问题，我们可以从多个角度进行排查和解决： 1. **检查InnoDB Buffer Pool**： - `innodb_buffer_pool_size` ...
1 概述 Android的设计理念之一，便是应用程序退出，但进程还会继续存在系统以便...Android基于Linux的系统，其实Linux有类似的内存管理策略——OOM killer，全称(Out Of Memory Killer), OOM的策略更多的是用于分配内存
例如，理解Linux内核的oom killer机制，它根据每个进程的oom_score来决定优先杀死哪个进程。oom_score是基于进程的内存使用情况和其他因素计算出来的，较高的值表示更容易被杀死。 此外，内核层面的优化还包括调整...
尽管LMK和标准Linux内核中的OOMKiller在设计思想上有许多相似之处，但两者之间还是存在一些重要的区别： 1. **实现方式：** LMK是作为一个Shrinker实现的，而OOMKiller则是在内存分配时被调用（如果内存资源非常...
在后续章节中，我们将深入探讨Linux OOM Killer的工作机制，以及如何避免MySQL因内存不足而被杀死的情况。了解并正确配置这些设置对于确保RDS（如网易云关系数据库服务）的稳定运行至关重要。通过优化内存管理和理解...
虽然Linux的oom killer能够应对大多数低内存情况，但在Android这种高度定制化的环境中，oom killer存在一些明显的局限性： - **响应速度慢**：oom killer通常在内存极度紧张时才会被触发，此时可能已经对用户体验...
oom killer在系统面临内存耗尽时，会选择杀死一些低优先级的进程，以保障关键服务的正常运行。 总的来说，理解Linux虚拟内存管理对于系统管理员、内核开发者和性能优化工程师至关重要。通过深入学习这一主题，我们...
oom-killer通常在Linux用户中享有不良声誉。 这可能是Linux仅在绝对没有其他选择时才调用它的部分原因。 它将换出桌面环境，删除整个页面缓存，并在最终终止进程之前清空每个缓冲区。 至少那是我认为的做法。 我坐...
8. **oom killer**：当系统出现严重的内存不足时，内核会启动OOM Killer，选择某些进程进行杀死，以释放内存供更重要的进程使用。 9. **内存泄漏检测**：Linux系统中可以使用 Valgrind 等工具进行内存泄漏检测，...
2. OOM killer 是被谁触发的。 3. 我的服务器内存去哪儿了。 4. CPU 占用不高但网络性能很差的一个原因。 三、Linux 主机网络问题 Linux 主机网络问题是 ECS 用户最常见的问题之一。该部分总结了一些可能会引起 ...
8. OOM（Out-Of-Memory）杀手：当系统内存耗尽时，Linux会启动OOM killer，选择杀死一些进程以释放内存。选择哪个进程被杀取决于其内存使用情况和优先级。 9. 内存管理工具：`free`命令显示当前系统的内存使用情况...