如何让 Linux OOM 终止程序不终止我的进程？

Question 1

这似乎是两个因素共同造成的问题：

使用虚拟机。
可能存在内核错误。

以下其中一行部分描述了为什么会发生这种情况：

3 月 7 日 02:43:11 myhost 内核：memcheck-amd64- 调用 oom-killer：gfp_mask=0x24002c2、order=0、oom_score_adj=0

另一行是这样的：

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

|第一行是分配给分配的 GFP 掩码。它基本上描述了内核允许/不允许做什么来满足此请求。掩码表示一组标准标志。然而，最后一位“2”表示内存分配应该来自区域HighMem。

如果仔细观察 OOM 输出，您会发现HighMem/Normal区域实际上并不存在。

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem（Normal在 x86_64 上通常也这样称呼）倾向于将内存映射到 32 位系统上内核可直接访问的标准 896MiB 范围之外的区域。在 x86_64 上HighMem/Normal似乎涵盖了大小超过 3GiB 的所有页面。

DMA32包含一个用于内存的区域，该区域可在 32 位 DMA 设备上访问，也就是说，您可以使用 4 字节指针对其进行寻址。我相信DMA是针对 16 位 DMA 设备的。

一般来说，在低内存系统上Normal不会存在，因为它DMA32已经覆盖了所有可用的虚拟地址。

您之所以会 OOM kill 是因为某个HighMem区域的内存分配中没有可用页面。由于内存不足处理程序根本无法通过交换、终止其他进程或任何其他技巧来让该区域有页面可用，因此 OOM-killer 会直接将其终止。

我认为这是由于主机 VM 在启动时膨胀造成的。在 KVM 系统上，您可以设置两个值。

當前的記憶。
可用内存。

其工作方式是，您可以热添加内存到您的服务器，直到达到可用内存为止。但您的系统实际上获得的是当前内存。

当 KVM VM 启动时，它会以可能分配的最大内存（可用内存）开始。在系统启动阶段，KVM 会通过膨胀逐渐收回这部分内存，让您保留当前的内存设置。

我相信这就是这里发生的事情。Linode 允许您扩展内存，在系统启动时为您提供更多内存。

Normal/HighMem这意味着在系统生命周期开始时有一个区域。当虚拟机管理程序将其膨胀时，正常区域会从内存管理器中消失。但是，我怀疑设置所述区域是否可从中分配的标志是不是应该清除时却被清除。这导致内核尝试从不存在的区域进行分配。

为了解决这个问题，您有两个选择。

在内核邮件列表中提出这个问题，看看这是否真的是一个错误，预期的行为，或者与我所说的完全无关。
请求 linode 将系统上的“可用内存”设置为与“当前内存”相同的 1GiB 分配。这样系统就不会膨胀，也不会在启动时进入正常区域，从而保持标志清晰。祝你好运让他们做到这一点！

您应该能够通过在 KVM 设置中设置您自己的虚拟机来测试这种情况，可用设置为 6GiB，当前设置为 1GiB，并使用相同的内核运行测试，以查看是否发生上述行为。如果发生，请将“可用”设置更改为等于当前 1GiB，然后重复测试。

我在这里做了一些有根据的猜测，并阅读了一些字里行间的内容以得出这个答案，但我所说的似乎符合已经概述的事实。

我建议测试我的假设并让我们都知道结果。

Answer