Linux服务器OOM卡死解决方案-earlyoom
1、业务痛点
经常我们会遇到这样的场景:业务云主机或虚机服务器频繁出现卡死,导致SSH无法登录,VNC远程黑屏、业务掉线。每次重启或断电重启后才能恢复正常。当然如果频繁OOM,那肯定是需要升级内存来解决的,但是针对偶发内存不足,避免服务器卡死,安装earlyoom是一个非常不错的解决方案。这里需要注意,业务一定配置服务自启,避免出现业务进程被earlyoom kill掉后,无法自动拉起,而增加故障影响时间。
2、什么是earlyoom?
开源安装包下载链接:https://github.com/rfjakob/earlyoom
earlyoom 是个用户态服务,顾名思义它会较早的触发(默认条件是可用物理内存和交换分区都不足10%),杀掉内存消耗最多的进程,避免系统卡死。核心机制是自动定时检查内存量和交换频率,从而主动kill。红帽的Fedora 32已经开始预置此软件。
3、Linux是如何处理内存不足情况的呢?
首先,由于Memory Overcommit机制的存在,操作系统承诺给进程的内存大小有可能会超过实际可用物理内存。当出现这种情况时,内核会通过OOM killer机制牺牲掉一个或者几个进程。相比系统崩溃,这个设计其实还是合理的。但是OOM killer存在不确定性的缺点:
- 内核oom要去kill进程,进而释放进程所占用的内存,但同时内核也需要一定的内存来执行oom的操作,有些时候内存剩余太少会导致内核无法释放掉进程的内存。
- 内核会通过特定的算法给每个进程计算一个分数来决定kill哪个进程,每个进程的oom分数可以在/proc/PID/oom_score中找到。每个进程都有一个oom_score的属性,oom killer会杀死oom_score较大的进程,当oom_score为0时禁止内核杀死该进程。
综合看,如果单靠内核的oom killer机制,完全是听天由命,用于业务生产,会造成不可预知性。
- oom killer本身触发的太迟;
- oom killer触发了也不一定能成功释放内存;
- oom killer评分靠算法,算法的优化依赖内核版本的提升;
4、CentOS系统安装教程
(1)下载并编译earlyoom安装包
[root@10-9-102-212 ~]# yum install git -y [root@10-9-102-212 ~]# git clone https://github.com/rfjakob/earlyoom.git [root@10-9-102-212 ~]# cd earlyoom/ [root@10-9-102-212 earlyoom]# make
(2)将earlyoom注册为服务并启动
make install # 注册到systemd make install-initscript # 取消注册non-systemd [root@10-9-102-212 earlyoom]# make install
(3)启动earlyoom服务并设置开机自启
[root@10-9-102-212 earlyoom]# systemctl enable earlyoom.service [root@10-9-102-212 earlyoom]# systemctl restart earlyoom.service [root@10-9-102-212 earlyoom]# systemctl status earlyoom.service ● earlyoom.service - Early OOM Daemon Loaded: loaded (/usr/lib/systemd/system/earlyoom.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2022-11-08 17:23:23 CST; 9min ago Docs: man:earlyoom(1) https://github.com/rfjakob/earlyoom Main PID: 555 (earlyoom) Tasks: 1 (limit: 10) CGroup: /system.slice/earlyoom.service └─555 /usr/local/bin/earlyoom -r 3600 -m 2,2 -s 100,100 -p -n Nov 08 17:23:23 10-9-52-138 systemd[1]: Started Early OOM Daemon. Nov 08 17:23:23 10-9-52-138 earlyoom[555]: earlyoom 1.6 Nov 08 17:23:23 10-9-52-138 earlyoom[555]: Notifying through D-Bus Nov 08 17:23:23 10-9-52-138 earlyoom[555]: Priority was raised successfully Nov 08 17:23:23 10-9-52-138 earlyoom[555]: mem total: 845 MiB, swap total: 0 MiB Nov 08 17:23:23 10-9-52-138 earlyoom[555]: sending SIGTERM when mem <= 2.00% and swap <= 100.00%, Nov 08 17:23:23 10-9-52-138 earlyoom[555]: SIGKILL when mem <= 2.00% and swap <= 100.00% Nov 08 17:23:23 10-9-52-138 earlyoom[555]: mem avail: 712 of 845 MiB (84.26%), swap free: 0 of 0 MiB ( 0.00%)
(4)查看当前实时内存使用情况
[root@10-9-102-212 earlyoom]# ./earlyoom earlyoom v1.7-14-g5dc02c8 mem total: 845 MiB, swap total: 0 MiB sending SIGTERM when mem <= 10.00% and swap <= 10.00%, SIGKILL when mem <= 5.00% and swap <= 5.00% mem avail: 620 of 845 MiB (73.40%), swap free: 0 of 0 MiB ( 0.00%) mem avail: 620 of 845 MiB (73.40%), swap free: 0 of 0 MiB ( 0.00%) mem avail: 620 of 845 MiB (73.40%), swap free: 0 of 0 MiB ( 0.00%) mem avail: 620 of 845 MiB (73.40%), swap free: 0 of 0 MiB ( 0.00%) mem avail: 620 of 845 MiB (73.40%), swap free: 0 of 0 MiB ( 0.00%) mem avail: 620 of 845 MiB (73.40%), swap free: 0 of 0 MiB ( 0.00%) mem avail: 620 of 845 MiB (73.40%), swap free: 0 of 0 MiB ( 0.00%) ……
注:Debian 10+、Ubuntu18.04+、Fedora、RHEL 8等系统,安装教程可直接参考官网。
作者:UStarGao
链接:https://www.starcto.com/systemtool/311.html
来源:STARCTO
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
UCloud云平台推荐
随便看看
- 2021-07-21MySQL主从同步异常之Relay log异常1594
- 2022-04-02Docker可视化管理工具-Portainer
- 2022-02-26Linux iptables控制网络访问
- 2021-06-23Linux性能异常经典案例分析之D进程
- 2023-08-18ubuntu修改hosts解析导致sudo命令卡住/hang住