现在是早上6点。 我清醒地总结了导致我太早醒来的电话的事件序列。 这些故事开始时，我的电话警报响了。 困倦而脾气暴躁的我检查了电话，看我是否真的疯了以至于无法在凌晨5点设置唤醒警报。 不，这是我们的监视系统，表明Plumbr服务之一已关闭。
作为该领域经验丰富的资深人士，我开启了浓缩咖啡机，朝着解决方案迈出了正确的第一步。 喝杯咖啡，我有能力解决这些问题。 首先怀疑的是，应用程序本身在崩溃之前似乎表现完全正常。 没有错误，没有警告标志，在应用程序日志中没有任何可疑的痕迹。
我们已经进行的监视已注意到该进程已终止，并且已经重新启动了崩溃的服务。 但是由于我的血液中已经含有咖啡因，所以我开始收集更多证据。 30分钟后，我发现自己盯着/var/log/kern.log中的以下内容：
Jun 4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child
Jun 4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB显然，我们成为了Linux内核内部的受害者。 众所周知，Linux是由一堆邪恶的生物（称为“ 守护程序 ”）构建的。 这些守护程序由多个内核作业管理，其中之一似乎特别危险。 显然，所有现代Linux内核都具有一种称为“ 内存不足杀手 ”的内置机制，该机制可以在极低内存条件下消除您的进程。 当检测到这种情况时，将启动杀手并选择要杀死的进程。 使用一组对所有过程进行评分的启发式方法选择目标，然后选择得分最差的目标来杀死目标。
了解“内存不足的杀手””
默认情况下，Linux内核允许进程请求的内存比系统中当前可用的内存更多。 考虑到大多数进程实际上从未真正使用过它们分配的所有内存，因此这在世界范围内都是有意义的。 与这种方法最简单的比较是与电缆运营商进行比较。 他们向所有消费者提供100Mbit的下载承诺，远远超出了他们网络中的实际带宽。 再次押注的事实是，用户将不会同时全部使用其分配的下载限制。 因此，一个10Gbit链路可以成功服务超过我们的简单数学所允许的100个用户。
如果您的某些程序正在耗尽系统内存的路径上，这种方法的副作用是显而易见的，这可能导致内存极低，无法分配任何页面进行处理。 您可能已经遇到过这样的情况，即使没有root帐户也无法杀死有问题的任务。 为防止此类情况，杀手启动并确定要杀死的进程。
您可以从RedHat文档中的本文中了解有关微调“ 内存不足杀手 ”行为的更多信息。
是什么触发了内存不足杀手？
现在我们有了上下文，仍然不清楚是什么触发了“杀手”，并在凌晨5点将我叫醒？ 更多调查显示：
- / proc / sys / vm / overcommit_memory中的配置允许过量使用内存–设置为1，表示每个malloc（）应该成功。
- 该应用程序在EC2 m1.small实例上运行。 EC2实例默认情况下已禁用交换。
这两个事实，再加上我们服务中流量的突然激增，导致应用程序请求越来越多的内存来支持那些额外的用户。 过量使用配置允许为这个贪婪的过程分配越来越多的内存，最终触发了“ 内存不足杀手 ”，他正在按照自己的意图去做。 在半夜杀死我们的应用程序并将我叫醒。
例
当我向工程师描述这种行为时，其中一位工程师很感兴趣，可以创建一个小的测试用例来重现错误。 在Linux上编译并启动以下Java代码段时（我使用了最新的稳定Ubuntu版本）：
package eu.plumbr.demo;
public class OOM {public static void main(String[] args){
java.util.List l = new java.util.ArrayList();
for (int i = 10000; i < 100000; i++) {try {l.add(new int[100_000_000]);} catch (Throwable t) {t.printStackTrace();}}
}
}那么您将面临同样的内存不足：杀死进程<PID>（java）得分<SCORE>或牺牲子消息。
请注意，您可能需要调整交换文件和堆大小，在我的测试用例中，我使用了通过-Xmx2g指定的2g堆以及以下配置进行交换：
swapoff -a
dd if=/dev/zero of=swapfile bs=1024 count=655360
mkswap swapfile
swapon swapfile解？
有几种方法可以处理这种情况。 在我们的示例中，我们只是将系统迁移到具有更多内存的实例。 我还考虑了允许交换，但是在咨询了工程人员之后，我想起了一个事实，那就是JVM上的垃圾回收进程不擅长在交换下运行，因此该选项不在讨论之列。
其他可能性包括微调OOM杀手 ，在几个小实例上水平扩展负载或减少应用程序的内存需求。
如果您发现研究有趣– 在Twitter或RSS 上关注Plumbr ，我们将继续发布有关Java内部知识的见解。
翻译自: https://www.javacodegeeks.com/2014/06/out-of-memory-kill-process-or-sacrifice-child.html
