频繁oomkill引发的hungtask

1 故障背景 4

2 故障分析 4

3 总结分析 9

4 解决方案 9

1故障背景

2023.6.28-2024.2.5共有5台网关服务器hang死。hang死服务器清单如下:

2023.06.28 节点:172.23.32.5(CLB内4,解决方案:重新加入集群)

2023.11.11 节点:172.23.32.193(eip,解决方案:自动恢复)

2023.12.28 节点:172.22.32.5(CLB内4,解决方案:重新加入集群)

2024.01.02 节点:172.23.32.5(CLB内4,解决方案:重新加入集群)

2024.2.5 节点:172.22.32.7(eip,解决方案:重新加入集群)

2故障分析

本次基于atop监控、vmcore日志、dmesg和message日志分析确认为boslog进程导致服务器hang死,具体分析如下:

1)通过atop监控可以看到在

11点53:22时 free:507.4M cache:9.4G

11点53:32时 free:9.9G cache:726.0M

atop里看基本没什么dirty page,free内存涨的时候,file cache释放出来,说明这个回收也不是回收dirty page,就是直接回收clean page

11点53:32内存回收的时候 flow进程D住了

2)通过vmcore日志发现当前处于收到一个信号的过程,随后 调用__getblk()等待可用的内存,目前由于 __getblk获取不到内存,于是不断地尝试调用 free_more_memory() 释放掉部分内存进行内存回收流程,卡到shrink_inactive_list。只有拿到足够内存,其对应的内核线程才能被唤醒。

3)查看 dmesg: flow进程oom的打印很多,kill掉的也是flow进程,内存堆栈里卡住的也是flow进程的内存回收的过程。

通过crash查看flow进程 属于cgroup

且flow与父进程状态也为睡眠状态(进程等待唤醒)详见下图:

补充:

1)查看部分机器,没出现hung住问题的系统都没有出现oom报错(系统内未安装flow进程,且系统中查看flow进程父进程为boslog进程)。

2)所有CLB类网关hang死服务器均安装boslog进程,没安装均为发生过hang死情况

3总结分析

Pod的flow进程在写IO时进getblk(),等待可用的内存,只有拿到足够内存,才能完成ext4_journal_stop()将t_updates 递减,其对应的内核Journal线程才能被唤醒,但是由于该pod的内存占用已经达到了其运行使用的上限,且无可回收的内存,导致进程触发了pod所在memory cgroup oom,但是由于引起oom的进程因为申请不到足够的内存无法从getblk()函数里退出到do_signal触发oom,kill收到信号杀死进程释放内存,最终引起了死环。

相关推荐
一心09243 分钟前
ubuntu 20.04.6 sudo 源码包在线升级到1.9.17p1
运维·ubuntu·sudo·漏洞升级
好好学习啊天天向上44 分钟前
世上最全:ubuntu 上及天河超算上源码编译llvm遇到的坑,cmake,ninja完整过程
linux·运维·ubuntu·自动性能优化
你想考研啊1 小时前
三、jenkins使用tomcat部署项目
运维·tomcat·jenkins
tan180°2 小时前
MySQL表的操作(3)
linux·数据库·c++·vscode·后端·mysql
代码老y2 小时前
Docker:容器化技术的基石与实践指南
运维·docker·容器
典学长编程2 小时前
Linux操作系统从入门到精通!第二天(命令行)
linux·运维·chrome
wuk9982 小时前
基于MATLAB编制的锂离子电池伪二维模型
linux·windows·github
你想考研啊5 小时前
四、jenkins自动构建和设置邮箱
运维·jenkins
Code blocks5 小时前
使用Jenkins完成springboot项目快速更新
java·运维·spring boot·后端·jenkins
snoopyfly~5 小时前
Ubuntu 24.04 LTS 服务器配置:安装 JDK、Nginx、Redis。
java·服务器·ubuntu