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

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

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

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

用户可以使用kill或Control+C杀死自己的程序，但我的印象是这并没有发生，而且用户向您投诉了。

Root当然有杀死程序的能力，但如果有人在你的机器上安装了Root并杀死了一些东西，你就有更大的问题了。

如果您不是系统管理员，系统管理员可能对CPU、RAM、磁盘使用设置了配额，并且会自动杀死超过配额的进程。

除了这些猜测，没有更多关于这个项目的信息，我不能确定。

像systemtap(或跟踪程序)这样的工具可以监视内核信号传输逻辑和报告。例如,https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap --example sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

该脚本中的过滤if块可以根据口味进行调整，也可以取消以跟踪系统范围的信号流量。可以通过收集回溯跟踪来进一步隔离原因(分别为内核和用户空间向探针添加print_backtrace()和/或print_ubacktrace())。

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

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

你可能还想复习man ulimit

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

Try:

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

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

在Mac OS上省略-T。