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

相关推荐
江团1io020 小时前
深入解析TCP核心机制:连接管理、流量与拥塞控制
服务器·网络·tcp/ip
磊灬泽20 小时前
【日常错误】鼠标无反应
linux·windows
知白守黑26720 小时前
Ansible角色
运维·服务器·ansible
Jwest202120 小时前
工业显示器在地铁电力监控与运维中的应用
运维·计算机外设
Miracle&1 天前
2.TCP深度解析:握手、挥手、状态机、流量与拥塞控制
linux·网络·tcp/ip
专注API从业者1 天前
Python/Java 代码示例:手把手教程调用 1688 API 获取商品详情实时数据
java·linux·数据库·python
Ribou1 天前
Ubuntu 24.04.2安装k8s 1.33.4 配置cilium
linux·ubuntu·kubernetes
tan180°1 天前
Boost搜索引擎 网络库与前端(4)
linux·网络·c++·搜索引擎
小小菜鸡ing1 天前
pymysql
java·服务器·数据库
Mr. Cao code1 天前
Docker:颠覆传统虚拟化的轻量级革命
linux·运维·ubuntu·docker·容器