我正在使用 Linux 5.15 和 Ubuntu 22.04。
我有一个使用大量内存的进程。它需要的内存比我机器上的 RAM 还要多。我第一次运行它时，它被 OOM Killer 杀死了。我的理解是：系统内存不足，OOM Killer 被触发，我的进程被杀死。这是有道理的。我也确信这就是发生的事情：我看了一下dmesg，一切都在那里。
所以我添加了一些交换空间。我不介意这个过程是否需要很长时间才能运行：我不会经常运行它。
我再次运行该过程。这次比第一次跑的时间更长。整个系统变得非常滞后，系统在进行大量交换时就会出现这种情况。它似乎起作用了……然后就死了。不仅进程死了，它的父进程 shell 进程也死了，它的父进程 Tmux 进程、Tmux 进程的父进程 shell 进程，甚至它的父 GNOME 终端进程也死了！但随后谋杀过程停止了：不再有父母死亡。
起初，我以为 OOM Killer 再次被触发——尽管仍有大量交换空间可用——并且它选择终止 GNOME 终端进程。但我查了dmesg一下，journalctl -k并没有什么新的东西。没有任何迹象表明 OOM Killer 已被触发。
那么，第一个问题：是否有任何情况可以触发 OOM Killer，而不将任何内容记录到内核环形缓冲区？
让我困惑的是，Linux 内核似乎已经开始交换，但不知何故它交换得不够……或者交换得不够快……或者其他什么。
所以我增加了vm.swappiness。这确实不应该影响系统稳定性：它只是一个用于性能优化的旋钮。即使vm.swappiness设置为0内核，当区域中的可用内存降至临界阈值以下时，内核仍应开始交换。
但似乎它已经开始交换，但交换得还不够……所以我增加了vm.swappiness鼓励100它交换更多一点。
然后我再次运行该过程。整个系统变得非常滞后，系统在进行大量交换时就会这样做......直到进程成功运行完成。
那么，第二个问题：为什么内核不使用可用的交换空间，即使空闲内存已降至临界阈值以下并且肯定有足够的可用交换空间？为什么改变会vm.swappiness带来改变？
更新：
进一步的测试表明该设置vm.swappiness不是一个可靠的解决方案。即使vm.swappinessset to ，我也遇到过一些失败100。它可能会提高该过程成功完成的机会，但我不确定。