频繁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收到信号杀死进程释放内存,最终引起了死环。

相关推荐
JuiceFS15 小时前
从 MLPerf Storage v2.0 看 AI 训练中的存储性能与扩展能力
运维·后端
CYRUS_STUDIO18 小时前
用 Frida 控制 Android 线程:kill 命令、挂起与恢复全解析
android·linux·逆向
熊猫李20 小时前
rootfs-根文件系统详解
linux
chen94521 小时前
mysql 3节点mgr集群部署
运维·后端
LH_R1 天前
OneTerm开源堡垒机实战(三):功能扩展与效率提升
运维·后端·安全
dessler1 天前
Hadoop HDFS-高可用集群部署
linux·运维·hdfs
泽泽爱旅行1 天前
awk 语法解析-前端学习
linux·前端
少妇的美梦2 天前
logstash教程
运维
chen9452 天前
k8s集群部署vector日志采集器
运维
chen9452 天前
aws ec2部署harbor,使用s3存储
运维