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

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

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

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

你可能还想复习man ulimit

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

PAM模块限制资源导致了您所描述的结果:我的进程神秘地死亡，控制台窗口上的文本为Killed。没有日志输出，无论是syslog还是kern.log。顶部程序帮助我发现，在CPU使用一分钟后，我的进程就会被杀死。

正如dwc和Adam Jaskiewicz所说，罪魁祸首很可能是OOM杀手。然而，接下来的问题是:我如何预防这种情况?

有几种方法:

如果可以的话，给你的系统更多的内存(如果是虚拟机，这很简单) 确保OOM杀手选择不同的进程。 禁用OOM杀手 选择一个禁用OOM杀手的Linux发行版。

多亏了这篇文章，我发现(2)特别容易实现。

这看起来是一篇关于这个主题的好文章:驯服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()规则背后原因的注释。