linux – OOM杀手变得疯狂

发布时间：2020-12-13 16:52:12 所属栏目：Linux 来源：网络整理

导读：在我们的集群上,当新进程请求太多内存时,我们有时会关闭节点.我很困惑为什么OOM杀手不仅仅是杀死了罪恶的过程. 原因是某些进程得到-17 oom_adj.这使得他们禁止OOM杀手(unkillabe！). 我可以通过以下脚本清楚地看到： #!/bin/bashfor i in `grep -v 0 /proc/*

在我们的集群上,当新进程请求太多内存时,我们有时会关闭节点.我很困惑为什么OOM杀手不仅仅是杀死了罪恶的过程.

原因是某些进程得到-17 oom_adj.这使得他们禁止OOM杀手(unkillabe！).

我可以通过以下脚本清楚地看到：

#!/bin/bash
for i in `grep -v 0 /proc/*/oom_adj | awk -F/ '{print $3}' | grep -v self`; do
  ps -p $i | grep -v CMD
done

好吧,它对sshd,udevd和dhclient有意义,但后来我看到常规用户进程也得到-17.一旦该用户进程导致OOM事件,它将永远不会被杀死.这导致OOM kiler疯狂. NFS rpc.statd,cron,碰巧不是-17的一切都将被消灭.结果节点关闭.

我有Debian 6.0(Linux 2.6.32-3-amd64).

有谁知道在哪里控制-17 oom_adj赋值行为？

可以从/etc/rc.local启动sshd和Torque mom会导致过度保护行为吗？

解决方法

它从产生它的过程中继承.如果SSH设置为-17,那么Bash将是.如果你通过Bash重新启动,你将进一步产生它.

[i-180ae177] root@migrantgeek ~ # pgrep mysqld_safe
11395
[i-180ae177] root@migrantgeek ~ # cat /proc/11395/oom_adj 
0
[i-180ae177] root@migrantgeek ~ # for pid in `pgrep bash`; do echo -17 >  /proc/$pid/oom_adj; done
[i-180ae177] root@migrantgeek ~ # /etc/init.d/mysqld  restart
Stopping MySQL:                                            [  OK  ]
Starting MySQL:                                            [  OK  ]
[i-180ae177] root@migrantgeek ~ # pgrep mysqld_safe
11523
[i-180ae177] root@migrantgeek ~ # cat /proc/11523/oom_adj 
-17

编辑init脚本以在启动过程结束时更改值应解决此问题.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!