文章目录

• 1. 查看Killed对应的日志
• • 1.1 触发Killed常见原因
  • 1.2 查看Killed日志
  • 1.3 dmesg输出信息说明
• 2. 释放无用内存占用
• • 2.1 查看系统内存情况
  • 2.2 修改OOM触发条件来解决OOM Killer
  • 2.3 释放无用内存
  • • 2.3.1 top命令
    • 2.3.2 其他查看内存的命令
    • 2.3.3 kill占用内存的无关进程
  • 2.4 vscode remote connection问题

训练一个神经网络的时候，中途出现 Killed，然后程序就被终止了。

• 因为以前遇到过这个问题，所以知道是因为内存不足所以系统将程序终止了。
• 不过这次想认真看一下系统日志，看一下内存等的消耗状况，然后再考虑解决方案。

1. 查看Killed对应的日志

1.1 触发Killed常见原因

当系统资源不足时，Linux 内核也可以决定终止一个或多个进程。 一个非常常见的例子是内存不足 (OOM) killer，会在系统的物理内存耗尽时触发。

• 当内存不足时，内核会将相关信息记录到内核日志缓冲区中，该缓冲区可通过 /dev/kmsg 获得。
• 有几个工具/脚本/命令 可以更轻松地从该虚拟设备读取数据，其中最常见的是 dmesg 和 journalctl。

1.2 查看Killed日志

使用sudo dmesg | tail -7命令（任意目录下，不需要进入log目录，这应该是最简单的一种）

hs@hs:~$ sudo dmesg | tail -7
[4772612.871775] [1125836]  1000 1125836     2539      911    61440        0             0 bash
[4772612.871777] [1126560]  1000 1126560     1787      474    53248        0             0 tmux: client
[4772612.871779] [1138439]  1000 1138439  2029489  1412461 12845056        0             0 python3
[4772612.871781] [1141425]  1000 1141425     1809       38    49152        0             0 sleep
[4772612.871783] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-1549.scope,task=python3,pid=1138439,uid=1000
[4772612.871840] Out of memory: Killed process 1138439 (python3) total-vm:8117956kB, anon-rss:5649844kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12544kB oom_score_adj:0
[4772612.968800] oom_reaper: reaped process 1138439 (python3), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

可以看到：

• oom-kill之后，就是解释那个被killed的程序的pid和uid
• Out of memory: Killed process 1138439 (python3) total-vm:8117956kB, anon-rss:5649844kB，内存不够
  • total_vm：总共使用的虚拟内存 Virtual memory use (in 4 kB pages)
    8117956/1024(得到MB)/1024(得到GB)=7.741GB
  • rss：常驻内存使用Resident memory use (in 4 kB pages)
    5649844/1024/1024=5.388GB

---

另外，网上还有几种方式，如下：

使用下面的这几行命令

journalctl --list-boots |
awk ‘{ print $1 }’ |
xargs -I{} journalctl --utc --no-pager -b {} -kqg ‘killed process’ -o verbose --output-fields=MESSAGE

就可以直接得到，最关键的信息

hs@hs:~$ journalctl --list-boots | \
>     awk '{ print $1 }' | \
>     xargs -I{} journalctl --utc --no-pager -b {} -kqg 'killed process' -o verbose --output-fields=MESSAGE
Mon 2022-02-14 08:48:43.684987 UTC [s=ed0a1ecfd36e41bda458e5e111c46e95;i=d4573;b=7bc379f894944dcd81ae32ff54afa009;m=456b0ad36d2;t=5d7f67bdee47b;x=5bfe01f8e2ca9b2c]
    MESSAGE=Out of memory: Killed process 1125888 (python3) total-vm:8530488kB, anon-rss:5653404kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12552kB oom_score_adj:0
Mon 2022-02-14 09:29:43.854158 UTC [s=ed0a1ecfd36e41bda458e5e111c46e95;i=d4785;b=7bc379f894944dcd81ae32ff54afa009;m=45743506aa5;t=5d7f70e82184e;x=9b55cfb2e7c081e7]
    MESSAGE=Out of memory: Killed process 1138439 (python3) total-vm:8117956kB, anon-rss:5649844kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12544kB oom_score_adj:0

---

网上更常见的似乎是：

journalctl -xb | egrep -i 'killed process’

hs@hs:~$ journalctl -xb | egrep -i 'killed process'
Feb 14 08:48:43 hs kernel: Out of memory: Killed process 1125888 (python3) total-vm:8530488kB, anon-rss:5653404kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12552kB oom_score_adj:0
Feb 14 09:29:43 hs kernel: Out of memory: Killed process 1138439 (python3) total-vm:8117956kB, anon-rss:5649844kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12544kB oom_score_adj:0
Feb 15 03:42:08 hs sudo[1151639]:       hs : TTY=pts/0 ; PWD=/home/hs ; USER=root ; COMMAND=/usr/bin/egrep -i -r killed process /var/log

---

以及

sudo dmesg | egrep -i -B100 'killed process'
# 但是这个会输出非常多的信息。。。

其中-B100，表示 'killed process’之前的100行内容

其中有一部分信息也许有用，如下所示，类似一个表格

• 重点关注其中最后两列：oom_score_adj和name
• 可以看到，有些服务常驻内存，所以占了不少内存，考虑清理出去。
• 同时killed之后，似乎有些内存，不会从内存中自动释放。需要手动释放。

[4770152.819134] Tasks state (memory values in pages):
[4770152.819135] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[4770152.819138] [    414]     0   414    70068     4518    90112        0         -1000 multipathd
[4770152.819142] [    704]     0   704    60330      698   106496        0             0 accounts-daemon
[4770152.819144] [    708]     0   708     2136      610    57344        0             0 cron

[4770152.819775] [    734]     0   734     7372     3870    94208        0             0 python3
[4770152.819777] [    735]     0   735      950      519    49152        0             0 atd

[4770152.819790] [   1033]     0  1033    82072     5590   131072        0             0 python3
[4770152.819792] [   1577]     0  1577     3046      915    61440        0         -1000 sshd
[4770152.819795] [  29492]  1000 29492     4663     1187    73728        0             0 systemd
[4770152.819798] [  29493]  1000 29493    42531     1196   102400        0             0 (sd-pam)
[4770152.819800] [ 135845]     0 135845   457433    38533   835584        0             0 nebula-metad
[4770152.819802] [ 135908]     0 135908   333667    24936   385024        0             0 nebula-graphd
[4770152.819804] [ 135927]     0 135927   592451   139719  1687552        0             0 nebula-storaged

[4770152.819818] [ 689086]     0 689086   292212     7132   286720        0          -900 snapd
[4770152.819821] [ 694790]  1000 694790     1779      641    61440        0             0 dbus-daemon
[4770152.819823] [ 699514]  1000 699514   407129     5193  1474560        0             0 node
[4770152.819825] [ 699523]  1000 699523   416398     7757  1634304        0             0 node
[4770152.819827] [ 699549]  1000 699549   489317    11361  2494464        0             0 node
[4770152.819830] [ 699555]  1000 699555   488416    10836  2531328        0             0 node
[4770152.819832] [ 699559]  1000 699559   488945    10316  2461696        0             0 node
[4770152.819835] [1102457]     0 1102457     3491     1010    65536        0             0 sshd
[4770152.819837] [1102573]  1000 1102573     3491      428    65536        0             0 sshd
[4770152.819839] [1102574]  1000 1102574     2215      574    57344        0             0 bash
[4770152.819841] [1102636]  1000 1102636      654      122    40960        0             0 sh
[4770152.819843] [1102643]  1000 1102643   403507   180866  3731456        0             0 node
[4770152.819845] [1102681]  1000 1102681   233944     6666  1265664        0             0 node
[4770152.819847] [1102707]  1000 1102707   221411    13611  2768896        0             0 node
[4770152.819849] [1102777]  1000 1102777     2535      952    49152        0             0 bash
[4770152.819851] [1103566]  1000 1103566   207746    13759   720896        0             0 node
[4770152.819853] [1110927]   113 1110927  2395391   627318  8884224        0             0 java
[4770152.819856] [1121028]  1000 1121028  1488563   907652  8630272        0             0 python3
[4770152.819858] [1125835]  1000 1125835     1983      659    49152        0             0 tmux: server
[4770152.819860] [1125836]  1000 1125836     2539      944    61440        0             0 bash
[4770152.819862] [1125888]  1000 1125888  2132622  1413351 12853248        0             0 python3
[4770152.819864] [1126560]  1000 1126560     1787      569    53248        0             0 tmux: client
[4770152.819867] [1137700]  1000 1137700     1809       38    49152        0             0 sleep

---

另外，还有
egrep -i ‘killed process’ /var/log/messages 或
egrep -i -r ‘killed process’ /var/log

hs@hs:~$ sudo egrep -i -r 'killed process' /var/log
Binary file /var/log/journal/482df032dea642279e0da48fa9dd4a1a/system.journal matches
/var/log/auth.log:Feb 15 03:42:08 hs sudo:       hs : TTY=pts/0 ; PWD=/home/hs ; USER=root ; COMMAND=/usr/bin/egrep -i -r killed process /var/log
/var/log/syslog.1:Feb 14 08:48:43 hs kernel: [4770152.820348] Out of memory: Killed process 1125888 (python3) total-vm:8530488kB, anon-rss:5653404kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12552kB oom_score_adj:0
/var/log/syslog.1:Feb 14 09:29:43 hs kernel: [4772612.871840] Out of memory: Killed process 1138439 (python3) total-vm:8117956kB, anon-rss:5649844kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12544kB oom_score_adj:0
/var/log/kern.log.1:Feb 14 08:48:43 hs kernel: [4770152.820348] Out of memory: Killed process 1125888 (python3) total-vm:8530488kB, anon-rss:5653404kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12552kB oom_score_adj:0
/var/log/kern.log.1:Feb 14 09:29:43 hs kernel: [4772612.871840] Out of memory: Killed process 1138439 (python3) total-vm:8117956kB, anon-rss:5649844kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12544kB oom_score_adj:0

---

1.3 dmesg输出信息说明

参考：Out of Memory events and decoding their logging

参数	解释
pid	进程ID
uid	用户ID
tgid	线程组ID
total_vm	总共使用的虚拟内存 Virtual memory use (in 4 kB pages)
rss	常驻内存使用Resident memory use (in 4 kB pages)
nr_ptes	页表实体Page table entries
swapents	页表实体Page table entries
oom_score_adj	通常为 0。较小的数字表示在调用 OOM 杀手时进程不太可能死亡。（oom会优先kill分数高的进程，分数高表示占用内存资源多）

---

参考：

• linux 程序被Killed，如何精准查看日志
• https://www.baeldung.com/linux/what-killed-a-process
• What killed my process and why?

2. 释放无用内存占用

2.1 查看系统内存情况

查看系统内存情况：cat /proc/meminfo

hs@hs:~$ cat /proc/meminfo
MemTotal:       14331380 kB
MemFree:         9515720 kB
MemAvailable:    9947704 kB
Buffers:          141952 kB

查看当前空闲内存：free -m(以MB显示内存情况)，free -g（以GB显示内存情况）

hs@hs:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          13995        4000        8308           1        1686        9656
Swap:             0           0           0
hs@hs:~$ free -g
              total        used        free      shared  buff/cache   available
Mem:             13           3           8           0           1           9
Swap:             0           0           0

2.2 修改OOM触发条件来解决OOM Killer

参考：Linux OOM-killer（内存不足时kill高内存进程的策略）

OOM_killer是Linux自我保护的方式，当内存不足时不至于出现太严重问题，有点壮士断腕的意味
在kernel 2.6，内存不足将唤醒oom_killer，挑出/proc/<pid>/oom_score最大者并将之kill掉

• 为了保护重要进程不被oom-killer掉，可以：

  • `echo -17 > /proc//oom_adj,-
    17表示禁用OOM

• 也可以对把整个系统的OOM给禁用掉：

  • sysctl -w vm.panic_on_oom=1 （默认为0，表示开启）
  • sysctl -p

• 值得注意的是，有些时候 free -m 时还有剩余内存，但还是会触发OOM-killer，可能是因为进程占用了特殊内存地址

  • 平常应该留意下新进来的进程内存使用量，免得系统重要的业务进程被无辜牵连
  • 可用 top M 查看最消耗内存的进程，但也不是进程一超过就会触发oom_killer

• 参数/proc/sys/vm/overcommit_memory可以控制进程对内存过量使用的应对策略

  • 当overcommit_memory=0 ，允许进程轻微过量使用内存，但对大量过载请求则不允许(默认）
  • 当overcommit_memory=1 ，永远允许进程overcommit
  • 当overcommit_memory=2，永远禁止overcommit

---

2.3 释放无用内存

2.3.1 top命令

查看某个用户的内存使用情况

查看当前内存使用情况，使用top命令，如果要查看某个用户的内存使用情况，可以top -u username，例如：

top -u hs  # 查看某个用户的内存使用情况

可以使用q退出top界面

---

查看详细的command内容

如果想查看详细的command，可以使用-c参数

top -u hs  -c

然后就会显示每个command的详细内容，例如：

---

查看特定PID或进程的资源消耗情况

进一步，如果希望查看这个用户下某个特定 command的占用情况，可以使用grep命令来进一步处理top命令的输出，参考：How to view a specific process in top

top -p `pgrep -d "," node`  # 正解

• top -p pid1,pid2: 展示多个进程信息，PID之间用逗号隔开
• pgrep -d "," java: 打印出所有含有java词的PID的信息
• 如果看到类似top: -p argument missing这样的提示，说明当前没有在运行的java程序，所以pgrep没有输出

输出以下内容：

为什么%MEM大于100%

参考：Sum of memory of few processes in top is greater than 100%

• 大致意思就是这里的%MEM会包含一些共享内存，这个东西不准，不要以top命令中的%MEM命令为准来判断程序的内存占用。
• 可以考虑使用其他命令查看内存情况

---

参考：Linux查看CPU和内存使用情况

top 运行中可以通过 top 的内部命令对进程的显示方式进行控制。内部命令如下表：

参数	解释
s	改变画面更新频率
l	关闭或开启第一部分第一行 top 信息的表示
t	关闭或开启第一部分第二行 Tasks 和第三行 Cpus 信息的表示
m	关闭或开启第一部分第四行 Mem 和 第五行 Swap 信息的表示
N	以 PID 的大小的顺序排列表示进程列表（第三部分后述）
P	以 CPU 占用率大小的顺序排列进程列表 （第三部分后述）
M	以内存占用率大小的顺序排列进程列表 （第三部分后述）
h	显示帮助
n	设置在进程列表所显示进程的数量
q	退出 top
s	改变画面更新周期

2.3.2 其他查看内存的命令

TBD

参考：

• How to Check Memory Usage Per Process on Linux
• How can I measure the actual memory usage of an application or process?

2.3.3 kill占用内存的无关进程

经过上面top命令的查看，其实发现，我系统很干净，只有nebula-graph-studio的4个进程以及使用vscode访问占用了一些资源。

因此，首先不再使用vscode访问服务器，改成xshell。

参考：too much memory for remote-ssh vscode

• vscode的远程连接确实比较费资源
• 一开始关闭VScode，很快打开xshell连上服务器之后，还是可以在xshell的界面里看到vscode的一些服务，但是过一会就会消失

---

然后关闭nebula-graph-studio服务。

---

关闭掉无关进程之后，可以看到，top命令中基本没东西了

再去查看free -g

似乎没什么用，哎。算了，那只能修改模型的batch_size了，或者把模型参数降低。

2.4 vscode remote connection问题

这里只记录一些我观察到的情况。

• 关闭vscode（直接关闭程序，不手动切断远程连接），使用mobaxtem查看系统内存使用情况，为3.83GB。(此时，vscode的连接进程还没有消失)
• 再打开vscode，内存使用增加到3.94GB
• 在vscode的远程命令行界面输入exit并关闭vscode，内存使用量变为3.84GB
• 关闭之后，大概需要等待5分钟，下面的三个进程才会消失，内存使用量变为3.77GB
  
• 同时，相比于mobaxterm中的openssh等进程，vscode的内存占用确实大很多，但是如果机器比较跟的上时代的话，其实不是很大的问题