背景
最近发现集群主节点总有进程宕机,定位了大半天才找到原因,分享一下
排查过程
查询hiveserver2和namenode日志,都是正常的,突然日志就不记录了,直到我重启之后又恢复工作了。
排查各种日志都是正常的,直到查看Grafana,发现内存满了
在这个节点下已无内存资源可用,在服务宕掉的节点内存使用突然下降,猜测是linux内核的杰作,故查询系统日志
grep "Out of memory" /var/log/messages
果然存在因OOM被杀掉的进程
进程被杀的原因
Linux 内核有个机制叫OOM killer,全称为 Out Of Memory killer,很形象的一个名字——内存溢出杀手,这个机制会监控那些占用内存过大,尤其是瞬间占用内存很快的进程,为防止机器内存耗尽而主动把该进程杀掉。
当内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码 linux/mm/oom_kill.c(2023-4-4 23:24:07确认了此文件存在),当系统内存不足的时候,out_of_memory() 函数被触发,然后调用 select_bad_process() 函数选择一个进程杀掉,这个选择的过程是通过调用 oom_badness() 函数实现的,挑选的算法和想法都暴力但朴实:就是找到最占用内存的进程。
出现问题的原因
最近刚刚增加了sentry和hivemetastore内存大小,导致机器内存不够了。
解决方案
1.调整机器进程分布,确保机器不会出现内存超用
2.可以通过设置/proc/sys/vm/overcommit_memory为不同的值来调整OverCommit策略。
overcommit_memory可以取3个值:
- 0:默认值,由Linux内核通过一些启发式算法来决定是否超售和超售的大小,一般允许轻微的超售,拒绝一些明显不可能提供的请求,同时做一些规则限制,比如不同用户overcommit的大小也不一样。
- 1:允许,不做限制的超售,当然这个也不是无限大,还受到寻址空间的限制,32位系统最大可能只有4G,64位系统大概16T左右。
- 2:禁止,禁止超售,系统能够分配的内存不会超过swap+实际物理内存*overcommit_ratio,该值可以通过/proc/sys/vm/overcommit_ratio设置,默认50%。
vi /etc/sysctl.conf
-- 添加
vm.overcommit_memory=1
-- 重启生效
sysctl -p
总结
如果你发现运行了一段时间的进程突然不见了,那可能是内核嫉妒生恨把它给干掉了
查询内存溢出被杀掉的进程可以直接通过系统日志来查 grep “Out of memory” /var/log/messages
也可以通过专门的命令查找 dmesg -T | grep “Out of memory”