当前位置:  开发笔记 > 编程语言 > 正文

什么杀了我的过程,为什么?

如何解决《什么杀了我的过程,为什么?》经验,为你挑选了8个好方法。

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

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

杀害

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

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



1> dwc..:

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


我刚刚写了一个程序,在一个inifite循环中malloc'd内存.系统变慢后,终端显示"已终止"并终止进程.文件/var/log/kern.log包含大量有关终止的信息. - 感谢指针.
使用`dmesg`查看内核日志:这里我发现由于极端的虚拟内存消耗,我的python进程被内核杀死了.
如果内核杀死了进程,它会在某个地方的日志中放入一条消息吗?
当"程序简单崩溃"时,*是*操作系统实际上正在杀死进程!
这几乎肯定是它.TAing时我看到了很多.许多学生会忘记释放他们的对象,应用程序最终将达到3GB的虚拟内存使用量.一旦它到达那一点它就被杀死了.
这是一篇关于如何保护您的进程不被杀害的好文章:http://backdrift.org/how-to-create-oom-killer-exceptions
无论使用何种语言,操作系统实际上都会终止进程.无法分配内存以各种语言处理,但通常是处理异常或检查返回状态.如果您已成功分配内存并且OOM杀手以您为目标,这将无济于事.
OOM杀手再次袭来!
这是内核OOM的杀手.我花了一段时间才找到这篇文章.http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

2> Ravindranath..:

尝试:

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

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

在Mac OS上省略-T.


在像''kill process'这样的简单模式的情况下,你可以使用`grep`而不是`egrep`而不需要其他更改.对于更复杂的模式,你可以用`grep -E -B100'foo | ba [rz]'`更改替换例如`egrep -i -B100'foo | ba [rz]'`.[此问答](http://stackoverflow.com/q/18058875/2359271)提供了更多详细信息.
仅供参考,来自`info egrep`:"egrep与grep -E相同......直接调用egrep或fgrep已被弃用"
我也建议使用`dmesg -T`以获得可读的时间戳

3> Adam Jaskiew..:

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

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

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


"Linux会给它那个空间,即使它被另一个进程声称"这不是虚拟内存的工作方式......
我真的很喜欢文章链接.我建议任何对这个主题感兴趣的人阅读它们 - 特别是关于这篇文章的评论.

4> 小智..:

我先解释一下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内存)

    查看日志和谷歌:)



5> mikemaccana..:

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

sudo journalctl -xb

您会看到如下消息:

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



6> Carl..:

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

有几种方法:

    如果可以的话,为您的系统提供更多内存(如果是VM,则很容易)

    确保OOM杀手选择不同的过程.

    禁用OOM杀手

    选择禁用OOM Killer附带的Linux发行版.

由于这篇文章,我发现(2)特别容易实现.



7> Christian Am..:

用于限制资源的PAM模块完全导致了您描述的结果:我的进程神秘地死于控制台窗口上的文本Killed.在syslogkern.log中都没有日志输出.该顶部程序帮助我发现CPU占用我的过程正好一分钟后就会被杀死.



8> fche..:

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

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

if可以调整该脚本中的过滤块以消除或消除以跟踪系统范围的信号流量.通过收集回溯(分别为内核和用户空间添加print_backtrace()和/或print_ubacktrace()探测)可以进一步隔离原因.

推荐阅读
李桂平2402851397
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有