我的应用程序在Linux上作为后台进程运行。它目前在终端窗口的命令行中启动。

最近,一个用户正在执行应用程序一段时间,它神秘地死亡了。文本:

杀了

在终端机上。这样发生了两次。我问是否有人在不同的终端使用kill命令杀死进程?不。

在什么情况下Linux会决定终止我的进程?我相信shell显示“已杀”是因为进程在接收到kill(9)信号后死亡。如果Linux发送了终止信号,系统日志中是否应该有一条消息解释为什么它被终止?


当前回答

我们在客户站点(我认为是Red Hat)的Linux下反复出现问题,OOMKiller(内存不足杀手)杀死了我们的主要应用程序(即服务器存在的原因)和它的数据库进程。

在每种情况下,OOMKiller只是简单地认为进程使用了太多的资源……这台机器甚至还没有因为缺乏资源而崩溃。应用程序及其数据库都没有内存泄漏(或任何其他资源泄漏)问题。

我不是Linux专家,但我认为它的算法决定什么时候杀死什么东西是复杂的。此外,我被告知(我不能说这是准确的),OOMKiller是烘焙到内核,你不能简单地不运行它。

其他回答

我最近遇到了这个问题。最后,我发现我的进程在自动调用Opensuse zypper更新后被杀死了。禁用zypper更新解决了我的问题。

让我先解释一下什么时候以及为什么调用OOMKiller ?

假设你有512内存+ 1GB交换内存。所以理论上,你的CPU总共可以访问1.5GB的虚拟内存。

现在,在总内存为1.5GB的情况下,一切运行正常。但是突然(或逐渐地),您的系统开始消耗越来越多的内存,它达到了总内存使用量的95%左右。

现在假设有任何进程向内核请求了大块内存。内核检查可用内存,发现无法为进程分配更多内存。因此,它将尝试调用/调用OOMKiller (http://linux-mm.org/OOM)来释放一些内存。

OOMKiller有自己的算法来为每个进程评分。通常,使用更多内存的进程将成为被杀死的受害者。

我在哪里可以找到OOMKiller的日志?

通常在/var/log目录下。/var/log/kern.log或/var/log/dmesg

希望这对你有所帮助。

一些典型的解决方案:

增加内存(不是交换) 找到程序中的内存泄漏并修复它们 限制任何进程可以使用的内存(例如,可以使用JAVA_OPTS限制JVM内存) 查看日志和谷歌:)

如果用户或系统管理员没有杀死内核可能已经杀死的程序。内核只会在特殊情况下终止进程,比如资源极度匮乏(比如mem+swap耗尽)。

在lsf环境中(交互式或其他),如果应用程序的内存利用率超过了队列上的管理员预先设定的阈值,或者提交给队列的资源请求,那么进程将被杀死,这样其他用户就不会成为潜在运行的受害者。当它这样做时,它并不总是发送电子邮件,这取决于它的设置方式。

在这种情况下,一种解决方案是找到具有更大资源的队列,或者在提交中定义更大的资源需求。

你可能还想复习man ulimit

虽然我不记得导致了死亡,但我需要它已经有一段时间了。

Try:

dmesg -T| grep -E -i -B100 'killed process'

其中-B100表示在kill发生之前的行数。

在Mac OS上省略-T。