8 种 Java 内存溢出之八 -Kill process or sacrifice child

本文最后更新于：2024年7月24日晚上

8.1 Kill process or sacrifice child 概述

为了理解这个报错, 我们需要复习一下操作系统基础知识. 正如你所知, 操作系统是建立在进程的概念之上的. 这些过程是由多个内核作业引导的，其中一个以内存杀手 (out of memory killer) 命名的 worker 在这个特殊的情况下是我们感兴趣的。

这个内核作业会在极低的内存条件下消灭您的进程. 当检测到这种情况时，内存杀手就会被激活，并选择一个进程来杀死。使用一组启发式算法对所有进程进行评分，并选择得分最差的一个作为目标。OutOfMemoryError: Kill process or sacrifice child这与我们的 OOM 手册中涉及的其他错误不同，因为它不是由 JVM 触发或代理的，而是构建在操作系统内核中的安全网络。

当可用的虚拟内存 (包括 swap) 被消耗到整个操作系统的稳定性受到威胁的程度时，就会产生 OutOfMemoryError: Kill process or sacrifice child 错误。在这种情况下，内存杀手会选择这个流氓进程并杀死它。

8.2 原因

默认情况下，Linux 内核允许进程请求比当前系统中可用的更多的内存。考虑到大多数进程实际上从未使用它们所分配的所有内存，因此这在现实世界是很有意义的。最简单的例子就是宽带运营商。他们向所有用户提供了 100Mbit 的下载承诺，远远超过了网络中实际的带宽(超卖)。再次打赌，用户绝不会同时使用他们分配的下载极限值。因此，一个 10Gbit 链接可以成功地服务于多于我们简单的数学算出来的 100 个用户。

这种方法的副作用是可见的，比如某些程序耗尽了系统内存。这可能导致极低的内存状态，没有页 (page) 可以分配到进程。您可能遇到过这样的情况，甚至连根帐户也不能杀死这个讨厌的任务. 为了防止这种情况，这个杀手激活了，并确认把这个流氓进程杀死.

您可以从这篇 RedHat 文档中阅读更多关于微调“内存杀手”行为的信息。

现在我们有了背景知识，那么你怎么知道是什么触发了“杀手”，并在凌晨 5 点叫醒了你? 激活的一个常见触发器隐藏在操作系统配置中。当您在 /proc/sys/vm/overcommit_memory 中检查配置时，您有了第一个提示 —— 特定的这个值表明是否允许所有 malloc()调用成功。注意，在 proc 文件系统中参数的路径取决于受更改影响的系统。超限提交配置允许为这个流氓过程分配越来越多的内存，最终可能触发“内存杀手”来完成它想要做的事情。

8.3 示例

当您在 Linux 上编译并启动以下 Java 代码片段时(我使用了最新的稳定 Ubuntu 版本):

package eu.plumbr.demo;
 
public class OOM {
 
public static void main(String[] args) {
    java.util.List<int[]> 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();
        }
    }
}
}

然后您将在系统日志中看到类似下列的错误 (/var/log/kern.login) 的例子:

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

注意，您可能需要调整 swapfile 和堆大小，在我们的测试用例中，我们使用了一个由 -Xmx2g 指定的 2g 堆，并有如下的 swap 配置:

swapoff -a
dd if=/dev/zero of=swapfile bs=1024 count=655360
mkswap swapfile
swapon swapfile

8.4 解决方案

有几种方式来解决这类场景. 解决这个问题的第一个也是最直接的方法是将系统迁移到具有更多内存的实例上。

其他的可能性包括对 OOM 杀手进行微调，在几个小的实例上横向扩展负载，或者减少应用程序的内存需求。

我们不愿意推荐的一个解决方案是增加交换空间。当您回想起 Java 是一种垃圾收集的语言时，这个解决方案似乎就不那么有利可图了. 现代 GC 算法在物理内存中运行效率很高，但是当处理 swap 分配时，效率会受到重创。Swapping 会增加 GC 暂停的长度高达几个数量级，所以在选择到这个解决方案之前，您应该三思而后行。

系列文章

Java

#Java #JVM #OOM

8 种 Java 内存溢出之八 -Kill process or sacrifice child

https://ewhisper.cn/posts/2643/

作者

东风微鸣

发布于

2017年11月3日

许可协议

「笔记」某移动 SRE 运维体系交流上一篇

8 种 Java 内存溢出之七 -Requested array size exceeds VM limit 下一篇