是否建议在 systemd 中为可替换服务设置 OOMScoreAdjust=1000？

Question

systemd 有一个OOMScoreAdjust选项，它允许调整启动进程的 oom-killer 分数。

引用systemd 文档：

OOMScoreAdjust=

为已执行的进程设置内存不足杀手的调整级别。取一个介于 -1000（禁用此进程的 OOM 终止）和 1000（在内存压力下很可能终止此进程）之间的整数。有关详细信息，请参阅proc.txt。

在我的设置中，我在 AWS 上部署了一个 NodeJs 服务器。除了 Node 服务器之外，EC2 实例上没有其他运行（除了监控和基本的 OS 进程）。有 ELB 运行状况检查，最终应该会替换损坏的 EC2 实例。

不过，我想知道如果OOMScoreAdjust存在内存问题，增加内核是否更喜欢杀死 Node 服务器进程是否被认为是一种好习惯，因为它可以自动重新启动。在 systemd 中，它可能如下所示：

OOMScoreAdjust=1000
Restart=always

我不得不承认我的理解是有限的。我目前的理解是它很可能不会产生真正的影响，最好保留默认值：

• 如果内存耗尽进程是 Node 服务器，它很可能无论如何都会被杀死。
• 如果罪魁祸首是另一个进程，重启 Node 服务器将无济于事，ELB 健康检查最终应该负责替换实例。

不过，我很好奇是否有更了解的人已经考虑过了。启用它只会是 systemd 脚本中的一行。如果有疑问，我宁愿让内核杀死 Node 进程，而不是任何随机系统服务。

Answer 1

在服务器只有一个进程的情况下，它可能不会产生很大的不同，但是如果您有一个经常泄漏内存的进程，这真的很重要。

例如在桌面上，Firefox 倾向于使用越来越多的内存，直到调用 OOM-killer，并且总是会决定 Xorg 使用最多的内存并将其杀死，从而导致整个桌面崩溃，而实际上它只是浏览器需要重新启动。

因此，在这种情况下，将泄漏程序设置为 OOM 分数为 1000 并立即重新启动不会有问题，因为它会首先被杀死，并且在重新加载时它不会像以前那样使用那么多内存，从而释放出整体记忆。

如果进程有相当恒定的内存使用，那么它不太可能重要（但肯定不会受到伤害），但如果它有泄漏，那么它可能会比让 AWS ELB 注意到问题并构建新 VM 更快地恢复。