消失的Java进程-Linux OOM Killer
在一台虚拟机上执行docker java应用,每隔一段时间就会出现java进程消失、而且没有任何jvm error log的情况。
略一寻思,应该是遇到网上常说的Linux OOM的情况:虚拟机10G,docker默认分配内存未做限制。
原因定位
去服务器上执行:dmesg | grep java
,果然有数据
并且查看文件: /var/log/messages
定位关键字:oom-killer,
看到相关信息:java pid信息,
memory: usage 2047696kB, limit 2047696kB, failcnt 23543
memory+swap: usage 2047696kB, limit 9007199254740991kB, failcnt 0
......
Free swap = 0kB
Total swap = 0kB
......
Memory cgroup out of memory: Kill process 18286 (java) score 933 or sacrifice child
复制代码
最终java进程被Linux OOM弄死了:因为oom的score太高了:933。启动的时候score是225,进程的oom_score 分数越高,越容易被 OOM Killer 杀掉。使用如下脚本检测oom score:
# vi oomscore.sh
#!/bin/bash
for proc in $(find /proc -maxdepth 1 -regex '/proc/[0-9]+'); do
printf "%2d %5d %s\n" \
"$(cat $proc/oom_score)" \
"$(basename $proc)" \
"$(cat $proc/cmdline | tr '\0' ' ' | head -c 50)"
done 2>/dev/null | sort -nr | head -n 10
# chmod +x oomscore.sh
复制代码
解决方案
在docker run命令中加入 -m 4000m ,未加这个时候默认swap是8000m。
网络上的方案:禁止OOM的方案
防止重要的系统进程触发(OOM)机制而被杀死:可以设置参数/proc/PID/oom_adj为-17,可临时关闭linux内核的OOM机制。内核会通过特定的算法给每个进程计算一个分数来决定杀哪个进程,每个进程的oom分数可以/proc/PID/oom_score中找到。我们运维过程中保护的一般是sshd和一些管理agent。
保护某个进程不被内核杀掉可以这样操作:
# echo -17 > /proc/$PID/oom_adj
复制代码
如何防止sshd被杀,可以这样操作:
# pgrep -f "/usr/sbin/sshd" | while read PID;do echo -17 > /proc/$PID/oom_adj;done
复制代码
可以在计划任务里加入这样一条定时任务,就更安全了:
#/etc/cron.d/oom_disable
*/1**** root pgrep -f "/usr/sbin/sshd" | while read PID;do echo -17 > /proc/$PID/oom_adj;done
复制代码
为了避免重启失效,可以写入/etc/rc.d/rc.local
echo -17 > /proc/$(pidof sshd)/oom_adj
复制代码
至于为什么用-17而不用其他数值(默认值为0),这个是由linux内核定义的,查看内核源码可知:
以linux-3.3.6版本的kernel源码为例,路径为linux-3.6.6/include/linux/oom.h,阅读内核源码可知oom_adj的可调值为15到-16,其中15最大-16最小,-17为禁止使用OOM。oom_score为2的n次方计算出来的,其中n就是进程的oom_adj值,所以oom_score的分数越高就越会被内核优先杀掉。
当然还可以通过修改内核参数禁止OOM机制
# sysctl -w vm.panic_on_oom=1
vm.panic_on_oom = 1 //1表示关闭,默认为0表示开启OOM
# sysctl -p
复制代码
看完三件事❤️
如果你觉得这篇内容对你还蛮有帮助,我想邀请你帮我三个小忙:
-
点赞,转发,有你们的 『点赞和评论』,才是我创造的动力。
-
关注公众号 『 java烂猪皮 』,不定期分享原创知识。
-
同时可以期待后续文章ing🚀