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

相关推荐
孙克旭_7 分钟前
day051-ansible循环、判断与jinja2模板
linux·运维·服务器·网络·ansible
渡我白衣33 分钟前
Linux操作系统之进程间通信:共享内存
linux
总有刁民想爱朕ha38 分钟前
零基础搭建监控系统:Grafana+InfluxDB 保姆级教程,5分钟可视化服务器性能!
运维·服务器·grafana
Mr_Orangechen1 小时前
Linux 下使用 VS Code 远程 GDB 调试 ARM 程序
linux·运维·arm开发
撰卢1 小时前
【个人笔记】负载均衡
运维·笔记·负载均衡
Shartin2 小时前
Can201-Introduction to Networking: Application Layer应用层
服务器·开发语言·php
lilian1292 小时前
linux系统mysql性能优化
linux·运维·mysql
共享家95272 小时前
linux_线程概念
linux·开发语言·jvm
apihz3 小时前
VM虚拟机全版本网盘+免费本地网络穿透端口映射实时同步动态家庭IP教程
android·服务器·开发语言·网络·数据库·网络协议·tcp/ip
乌云暮年3 小时前
Linux常用命令
linux·服务器·ssh·php