systemd 有一个OOMScoreAdjust选项，允许调整已启动进程的 oom-killer 分数。
引用systemd 文档：
OOMScoreAdjust=设置已执行进程的内存不足终止程序的调整级别。采用 -1000（禁用此进程的 OOM 终止）和 1000（使此进程在内存压力下很可能终止）之间的整数。请参阅进程.txt了解详情。
在我的设置中，我在 AWS 上部署了一个 NodeJs 服务器。除了 Node 服务器之外，EC2 实例上没有太多其他运行的东西（除了监控和必要的操作系统进程）。有 ELB 健康检查，最终应该会取代损坏的 EC2 实例。
不过，我不知道增加OOMScoreAdjust内核以在出现内存问题时优先终止 Node 服务器进程是否是一种好的做法，因为它可以自动重新启动。在 systemd 中，它可能看起来像这样：
OOMScoreAdjust=1000
Restart=always
我必须承认我的理解是有限的。我目前的理解是，这很可能不会产生真正的影响，最好保留默认设置：
- 如果消耗内存的进程是 Node 服务器，那么它很可能会被终止。
- 如果罪魁祸首是另一个进程，则重新启动 Node 服务器将无济于事，并且 ELB 运行状况检查最终应该负责替换该实例。
不过，我很好奇是否有人比我更了解这一点。启用它只需要在 systemd 脚本中添加一行。如果有疑问，我宁愿让内核终止 Node 进程，而不是任何随机系统服务。
答案1
对于只有一个进程的服务器来说，这可能不会产生很大的差异，但是如果您有一个经常泄漏内存的进程，那么这确实会产生影响。
例如在桌面上，Firefox 倾向于使用越来越多的内存，直到调用 OOM-killer，并且它总是会认为 Xorg 使用了最多的内存并将其杀死，从而关闭整个桌面，而实际上只需要重新启动浏览器。
因此在这种情况下，将泄漏的程序设置为 OOM 分数为 1000 并立即重新启动不会有问题，因为它会首先被杀死，并且当它重新加载时它不会像以前那样使用那么多内存，从而释放整体内存。
如果该过程具有相当恒定的内存使用量，那么它不太可能产生影响（但肯定不会造成损害），但如果它有泄漏，那么它可能会导致比让 AWS ELB 注意到问题并构建新的 VM 更快的恢复。