原文链接:https://www.javacodegeeks.com/2014/06/out-of-memory-kill-process-or-sacrifice-child.html
版权
linux 内存不足杀进程
现在是早上六点。 我清醒地总结了导致我太早唤醒电话的事件顺序。 这些故事开始时,我的电话警报响了。 困倦而脾气暴躁的我检查了电话,看我是否真的疯了以至于无法在凌晨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文档中的本文中了解有关微调“Out of memory Killer”行为的更多信息。

是什么触发了内存不足杀手?

现在我们有了背景,现在还不清楚是什么触发了“杀手””并在凌晨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