关于linux：什么杀了我的进程，为什么？


What killed my process and why?

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

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

Killed

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

在什么条件下Linux会决定杀死我的进程？ 我相信shell显示"已杀死"，因为该进程在收到kill(9)信号后死亡。 如果Linux发送了kill信号，系统日志中是否会有消息说明它被杀的原因？

相关讨论

如果用户或系统管理员没有杀死内核可能拥有的程序。内核只会在特殊情况下杀死进程，例如极端资源匮乏(想想mem + swap exhaustion)。

相关讨论

尝试：

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

其中-B100表示杀戮发生前的行数。

在Mac OS上省略-T。

相关讨论

这看起来像是关于这个主题的好文章：驯服OOM杀手。

要点是Linux过度使用内存。当一个进程要求更多空间时，Linux会给它那个空间，即使它被另一个进程声明，假设没有人真正使用他们要求的所有内存。该进程将独占使用它在实际使用时分配的内存，而不是在它要求时使用。这样可以快速进行分配，并且可能允许您"欺骗"并分配比实际更多的内存。但是，一旦进程开始使用这个内存，Linux可能会意识到它在分配它没有的内存时过于慷慨，并且必须杀死一个进程以释放一些内存。要杀死的过程基于考虑运行时的分数(长时间运行的过程更安全)，内存使用(贪婪过程不太安全)以及一些其他因素，包括您可以调整以减少过程的值可能会被杀死。这一切都在文章中进行了更详细的描述。

编辑：这是另一篇文章，很好地解释了如何选择一个过程(用一些内核代码示例注释)。关于这一点的好处在于它包含了对各种badness()规则背后的推理的一些评论。

相关讨论

我先解释一下OOMKiller被调用的时间和原因？

假设您有512 RAM + 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内存)
  • 查看日志和谷歌:)

    • 这是Linux内存管理器(OOM)。您的流程是由于"不良"而选择的 - 最近性，居住大小(使用中的内存，而不仅仅是已分配)和其他因素的组合。

    1
    sudo journalctl -xb

    您会看到如下消息：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    Jul 20 11:05:00 someapp kernel: Mem-Info:
    Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
    Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
    Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
    Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
    Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                        active_file:722 inactive_file:4126 isolated_file:0
                                        unevictable:0 dirty:5 writeback:0 unstable:0
                                        free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                        mapped:792 shmem:12802 pagetables:1651 bounce:0
                                        free_cma:0
    Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
    Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
    Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
    Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
    Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
    Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
    Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
    Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
    Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
    Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
    Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
    Jul 20 11:05:00 someapp kernel: Total swap = 0kB
    Jul 20 11:05:00 someapp kernel: 262141 pages RAM
    Jul 20 11:05:00 someapp kernel: 7645 pages reserved
    Jul 20 11:05:00 someapp kernel: 264073 pages shared
    Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
    Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
    Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
    Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
    Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
    Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
    Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
    Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
    Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
    Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
    Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
    Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
    Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
    Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
    Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
    Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
    Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
    Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
    Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
    Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
    Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
    Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
    Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
    Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
    Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
    Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
    Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
    Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
    Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
    Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
    Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
    Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
    Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

    正如dwc和Adam Jaskiewicz所说，罪魁祸首可能是OOM杀手。但是，接下来的问题是：如何防止这种情况发生？

    有几种方法：

  • 如果可以的话，为您的系统提供更多内存(如果是VM，则很容易)
  • 确保OOM杀手选择不同的过程。
  • 禁用OOM杀手
  • 选择禁用OOM Killer附带的Linux发行版。

    • 由于这篇文章，我发现(2)特别容易实现。

    用于限制资源的PAM模块完全导致了您描述的结果：我的进程神秘地死于控制台窗口上的文本Killed。在syslog和kern.log中都没有日志输出。顶级程序帮助我发现，在一分钟的CPU使用后，我的进程被杀死了。

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

    1
    2
    3
    # stap .../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

    虽然我不记得ulimit导致Killed因为我需要它已经有一段时间了。

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

    在每种情况下，OOMKiller只是决定这些流程用于大量资源......由于缺乏资源，机器甚至不会失败。应用程序及其数据库都没有内存泄漏问题(或任何其他资源泄漏)。

    我不是Linux专家，但我宁愿收集它的算法来决定何时杀死某些东西以及杀死什么是复杂的。另外，我被告知(我不能说这个的准确性)，OOMKiller被烘焙到内核中，你不能简单地不运行它。

    相关讨论

    在我的情况下，这发生在一个Laravel队列工作者身上。系统日志没有提到任何查杀，所以我进一步查看，结果发现工作人员基本上是因为超出内存限制的工作而自杀(默认情况下设置为128M)。

    使用--timeout=600和--memory=1024运行队列工作程序为我解决了问题。

    通过增加交换大小解决了这个问题：

    https://askubuntu.com/questions/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04

    相关讨论

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

    相关讨论

    用户可以使用kill或Control + C杀死他自己的程序，但我得到的印象不是发生了什么，并且用户向你抱怨。

    root当然有杀死程序的能力，但是如果有人在你的机器上有root并且杀了东西你就会遇到更大的问题。

    如果您不是系统管理员，则系统管理员可能已设置CPU，RAM，ort磁盘使用情况的配额以及超过它们的自动杀死进程。

    除了那些猜测，我不确定没有关于该计划的更多信息。

    相关讨论