我的应用程序在Linux上作为后台进程运行。它目前在终端窗口的命令行中启动。
最近,一个用户正在执行应用程序一段时间,它神秘地死亡了。文本:
杀了
在终端机上。这样发生了两次。我问是否有人在不同的终端使用kill命令杀死进程?不。
在什么情况下Linux会决定终止我的进程?我相信shell显示“已杀”是因为进程在接收到kill(9)信号后死亡。如果Linux发送了终止信号,系统日志中是否应该有一条消息解释为什么它被终止?
我的应用程序在Linux上作为后台进程运行。它目前在终端窗口的命令行中启动。
最近,一个用户正在执行应用程序一段时间,它神秘地死亡了。文本:
杀了
在终端机上。这样发生了两次。我问是否有人在不同的终端使用kill命令杀死进程?不。
在什么情况下Linux会决定终止我的进程?我相信shell显示“已杀”是因为进程在接收到kill(9)信号后死亡。如果Linux发送了终止信号,系统日志中是否应该有一条消息解释为什么它被终止?
当前回答
这看起来是一篇关于这个主题的好文章:驯服OOM杀手(1)。
The gist is that Linux overcommits memory. When a process asks for more space, Linux will give it that space, even if it is claimed by another process, under the assumption that nobody actually uses all of the memory they ask for. The process will get exclusive use of the memory it has allocated when it actually uses it, not when it asks for it. This makes allocation quick, and might allow you to "cheat" and allocate more memory than you really have. However, once processes start using this memory, Linux might realize that it has been too generous in allocating memory it doesn't have, and will have to kill off a process to free some up. The process to be killed is based on a score taking into account runtime (long-running processes are safer), memory usage (greedy processes are less safe), and a few other factors, including a value you can adjust to make a process less likely to be killed. It's all described in the article in a lot more detail.
编辑:下面是[另一篇文章](2),它很好地解释了如何选择进程(带有一些内核代码示例的注释)。它的优点在于,它包含了一些关于各种bad()规则背后原因的注释。
其他回答
这看起来是一篇关于这个主题的好文章:驯服OOM杀手(1)。
The gist is that Linux overcommits memory. When a process asks for more space, Linux will give it that space, even if it is claimed by another process, under the assumption that nobody actually uses all of the memory they ask for. The process will get exclusive use of the memory it has allocated when it actually uses it, not when it asks for it. This makes allocation quick, and might allow you to "cheat" and allocate more memory than you really have. However, once processes start using this memory, Linux might realize that it has been too generous in allocating memory it doesn't have, and will have to kill off a process to free some up. The process to be killed is based on a score taking into account runtime (long-running processes are safer), memory usage (greedy processes are less safe), and a few other factors, including a value you can adjust to make a process less likely to be killed. It's all described in the article in a lot more detail.
编辑:下面是[另一篇文章](2),它很好地解释了如何选择进程(带有一些内核代码示例的注释)。它的优点在于,它包含了一些关于各种bad()规则背后原因的注释。
我最近遇到了这个问题。最后,我发现我的进程在自动调用Opensuse zypper更新后被杀死了。禁用zypper更新解决了我的问题。
Try:
dmesg -T| grep -E -i -B100 'killed process'
其中-B100表示在kill发生之前的行数。
在Mac OS上省略-T。
正如dwc和Adam Jaskiewicz所说,罪魁祸首很可能是OOM杀手。然而,接下来的问题是:我如何预防这种情况?
有几种方法:
如果可以的话,给你的系统更多的内存(如果是虚拟机,这很简单) 确保OOM杀手选择不同的进程。 禁用OOM杀手 选择一个禁用OOM杀手的Linux发行版。
多亏了这篇文章,我发现(2)特别容易实现。
在lsf环境中(交互式或其他),如果应用程序的内存利用率超过了队列上的管理员预先设定的阈值,或者提交给队列的资源请求,那么进程将被杀死,这样其他用户就不会成为潜在运行的受害者。当它这样做时,它并不总是发送电子邮件,这取决于它的设置方式。
在这种情况下,一种解决方案是找到具有更大资源的队列,或者在提交中定义更大的资源需求。
你可能还想复习man ulimit
虽然我不记得导致了死亡,但我需要它已经有一段时间了。