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