☰

如何检查我的服务进程被Linux杀死的原因？

tag-icon • tag-icon linux ubuntu systemd swap oom
如何检查我的服务进程被Linux杀死的原因？

我在 Ubuntu(20.04.1) 服务器上运行一项重要服务。最近它总是被操作系统杀死。

一开始我猜想可能是因为 OS 的 OOM(out of memory) 操作导致的，所以我修改了我的应用程序的 systemd 服务单元文件(my_app.service)，并添加了一个选项OOMScoreAdjust=-1000。当然后面跟着一个systemctl daemon-reload。

但是我的应用程序仍然被操作系统杀死了！

现在我必须检查操作系统总是终止我的应用程序的真正原因。

顺便说一句，有 2G RAM 和 4G 交换空间。当我的应用程序被杀死时，几乎整个交换空间都是空闲的。我的应用程序应该是一个好程序，因为它在另一台具有 4G RAM 和 4G 交换空间的 Ubuntu(20.04) 服务器上正常运行。

如何找出真正的原因？（/proc/sys/vm/swapness 为 65）

任何提示都将受到赞赏！

答案1

我认为你可以用而OOMPolicy不是使用来修复问题OOMScoreAdjust，请参考此页面https://www.freedesktop.org/software/systemd/man/systemd.service.html#

OOMPolicy=
配置内存不足 (OOM) 内核终止策略。请注意，用户空间 OOM 终止程序 systemd-oomd.service(8) 是一种更灵活的解决方案，旨在防止用户空间（而不仅仅是内核）出现内存不足的情况。在 Linux 上，当内存变得稀缺到内核无法为自己分配内存的程度时，它可能会决定终止正在运行的进程，以释放内存并减少内存压力。此设置采用 continue、stop 或 kill 之一。如果设置为 continue，并且服务的进程被内核的 OOM 终止程序终止，则会记录此事件，但服务会继续运行。如果设置为 stop，则会记录事件，但服务管理器会干净地终止服务。如果设置为 kill，并且服务的进程之一被 OOM 终止程序终止，则会指示内核通过将 memory.oom.group 属性设置为 1 来终止服务的所有剩余进程；另请参阅内核文档。

DefaultOOMPolicy=
配置对 Linux 内存不足 (OOM) 终止程序或 systemd-oomd 终止的进程做出反应的默认策略。这可用于为每个单元的 OOMPolicy= 设置选择全局默认值。有关详细信息，请参阅 systemd.service。请注意，此默认值不用于已启用 Delegate= 的服务。

DefaultOOMScoreAdjust=
配置服务管理器运行的进程的默认 OOM 分数调整。默认为未设置（意味着分叉的进程继承服务管理器的 OOM 分数调整值），除非服务管理器是为非特权用户运行的，在这种情况下默认为服务管理器的 OOM 调整值加 100（这使得服务进程在内存压力下被杀死的可能性比管理器本身略高）。这可用于为每个单元的 OOMScoreAdjust= 设置选择全局默认值。有关详细信息，请参阅 systemd.exec。请注意，此设置对服务管理器进程本身的 OOM 分数调整值没有影响，它保留其调用期间设置的原始值。

相关内容