这 8 类问题,SysOM 2.0 OOM 诊断助你快速定位异常 | 龙蜥技术

简介: 关键业务中断、系统无法运行,深受 OOM “迫害”该怎么办?

1 (2).png

文/刘馨蔚,系统运维 SIG Contributor


小 A 准备下班时,突然收到云上专门对接客户前线同事电的话。“小 A,小 A,一个我们游戏的大客户的集群出了问题,影响了业务,需要紧急排查一下”,小 A 也听出了紧急,放下包叹了口气,心想“刚和老婆说回去吃饭呢,看来赶不上咯”。小 A 立马回到办公桌向前线同事了解详细情况,原来这个大客户云上 pod 内业务突然不可用,检查后发现有 OOM Killed 的报警,但是发现 pod 的使用内存并没有到阈值 limit 的 8G,请求排查 OOM 的原因并希望给出相关建议避免同样情况再次发生。


小 A 详细了解情况后,定位到是和 OOM 相关的问题。这时小 A 突然想到了团队内开发了针对 OOM 的诊断分析的功能,再向同事确认客户也安装了 SysOM 后建议客户立马进行 SysOM 中的 OOM 诊断。根据 OOM 诊断后诊断出了如下结果:

1.png

图中可以看出发生了两次 OOM,并且怀疑有内存泄漏,内核占用了近 5G 的内存,将这个结果和前线同事对齐后,结合客户的系统日志“TCP out of memory.”等字样,排查出问题的原因是业务接收数据不及时,导致数据驻留在内核中。此时建议客户优化业务程序,及时处理接收队列中的数据报文,并通过重启业务止血。


前线的同事纷纷点赞小 A 的排查速度和 SysOM 中诊断功能的省时省力,还让小 A 赶紧介绍一下 SysOM 的这个 OOM 诊断。小 A 也对这个工具也十分熟悉,就和前线的同事好好介绍了介绍:


OOM(Out of memory) 是日常或生产环境中比较容易碰到的异常,当 OOM 发生时一般伴随着在内核日志中打印相关异常信息和某个进程被 Kill 掉的现象:

test invoked oom-killer: gfp_mask=0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0


OOM 发生在 Linux 在整机或 cgroup 剩余内存低于水线时,如果通过内存回收、规整等方式都无法满足内存分配操作,便会触发 OOM killer 流程来强行释放进程内存,如下图所示:

2.png

有一部分小伙伴觉得 OOM 根本不算什么异常,甚至如果不看日志的话根本没有感知到;但是有一部分小伙伴却深受 OOM 的“迫害”,因为 OOM 可能会导致关键业务中断,甚至系统无法正常运行等现象。SysOM 的 OOM 诊断可以检测 8 类 OOM 的问题,具体如下图所示:

3.png

当发生了 OOM 的问题时,可以通过 SysOM 的 OOM 检测来对系统的 OOM 提供快速检测、分析和提供修复建议。

4.png

例如整机内存低于水线时,通过 SysOM 的 OOM 诊断可以得到如下界面:

5.png

SysOM 检测页面给出了 OOM 当时的内存情况、发生原因和使用内存 TOP 10 的内存使用排名,结果表明这是属于 host 内存 limit 造成的 OOM。这种情况下我们可以:

1、先评估使用内存多的业务进程内存占用是否合理,必要时优化业务进程内存申请量。

2、还排查进程 oom_score_adj 设置是否合理,不合理的 oom_score_adj 值会导致进程占用大量内存而不被 kill 掉。


例如 cgroup 发生 OOM 时,通过 OOM 诊断可以得到如下界面:

7.png

可以看到是由于进程 test 所在的 cgroup mm_test 发生 OOM,原因为 cgroup 内存usage 达到 limit 值(90M)。这种情况下我们能够比较快速直接的判断出是 cgroup 内存 usage 达到了上限,我们可以调整使用情况或者 cgroup 的内存可用上限。除了使用达到 limit,oomcheck 还有检测 shmem 泄漏导致的 OOM。

总的来说,OOM 主要可以分为整机和 cgroup 级别的异常,SysOM 中的 OOM 诊断可以快速准确的定位到系统发生的 OOM 异常,从而用户可以根据不同的原因应用不同的方法解决 OOM。


小 A 向前线同事介绍完后,大家都表示以后的问题排查、诊断效率肯定有很大的提升。和同事、客户都交接好后,小 A 感叹着 SysOM 对系统、内核的各种诊断能力的健全,省时省力,快速定位到异常问题的同时也能够指引下一步解决方案。哼着小曲儿回家后,小 A 发现老婆热的汤还是暖呼呼的呢。


龙蜥大讲堂 SysOM 2.0 系列直播《SysOM 2.0 内存相关功能介绍》中讲解了内存诊断中心功能的基本使用和应用场景,展示了三个内存诊断的使用参数和结果分析,也在官网上进行了实时演示。视频回放及 PPT 课件获取见下:


【PPT 课件获取】:关注微信公众号(OpenAnolis),回复“龙蜥课件” 即可获取。有任何疑问请随时咨询龙蜥助手—小龙(微信:openanolis_assis)。

【视频回放】:视频回放可前往龙蜥官网 https://openanolis.cn/video 查看。

—— 完 ——

加入龙蜥社群

加入微信群:添加社区助理-龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】与你同在;加入钉钉群:扫描下方钉钉群二维码。

6.png

相关文章
|
7月前
|
安全 Linux 测试技术
提升龙蜥内核测试能力!探究持续性模糊测试优化实践
清华大学软件学院对Anolis OS使用靶向模糊测试方法将测试工作引向修改的代码,进而提高对业务代码的测试能力。
|
5月前
|
运维 监控 Java
(十)JVM成神路之线上故障排查、性能监控工具分析及各线上问题排错实战
经过前述九章的JVM知识学习后,咱们对于JVM的整体知识体系已经有了全面的认知。但前面的章节中,更多的是停留在理论上进行阐述,而本章节中则更多的会分析JVM的实战操作。
135 1
|
4月前
|
监控 关系型数据库 Linux
肝了这么多夜,总结一下:Linux各项指标监控及问题排查。
肝了这么多夜,总结一下:Linux各项指标监控及问题排查。
|
开发框架 运维 监控
带你读《2022龙蜥社区全景白皮书》——5.9.1 SysAK:大规模复杂场景的系统运维利器
带你读《2022龙蜥社区全景白皮书》——5.9.1 SysAK:大规模复杂场景的系统运维利器
188 5
|
Arthas Java 测试技术
59-微服务技术栈(高级):在线检测工具Arthas(精准定位Java应用CPU负载过高)
开发者对于生产问题故障的排查、定位,随着微服务的喷发,也不再像是以前那边依赖纯日志、gc日志进行问题排查与定位了,本节开始介绍一个生产环境使用的排错工具Arthas,帮助大家更高效、便捷地实现生产问题排错。
297 0
|
运维 算法 调度
干货演讲!龙蜥自动化运维平台SysOM 2.0调度、内存相关诊断功能介绍 | 第 70-71 期
了解内存诊断相关功能使用、可能的异常类型和发生异常后的后续动作。提供案例展示,方便用户理解可应用场景。
干货演讲!龙蜥自动化运维平台SysOM 2.0调度、内存相关诊断功能介绍 | 第 70-71 期
|
机器学习/深度学习 人工智能 弹性计算
今天 4 点,龙蜥自动化运维平台SysOM 2.0的诊断中心功能介绍 | 第 66-68 期
本周 3 场直播来袭:SysOM 2.0 系列直播、Intel HE Toolkit 介绍及阿里云在使能 AMX 技术方面的进展。
今天 4 点,龙蜥自动化运维平台SysOM 2.0的诊断中心功能介绍 | 第 66-68 期
|
弹性计算 运维 监控
系统运维 SysOM profiling 在云上环境的应用观测实践 | 龙蜥技术
通过部署 profiling,直击 CPU 指标异常等问题的第一现场。
系统运维 SysOM profiling 在云上环境的应用观测实践 | 龙蜥技术
|
Arthas NoSQL Java
线上服务器CPU100%的真相排查【Bug利器Arthas】
这起CPU100%的事故,由某个客户演示的bug暴露出来,气氛比较尴尬....
770 0
线上服务器CPU100%的真相排查【Bug利器Arthas】