OOM 排查：区分应用退出与系统内存事件

阅读原文 ↗

阅读摘要

原文围绕 OOM 处置的末端路径，讨论终止进程、诊断日志、内存组处理以及 panic_on_oom 策略。它强调在内存异常后保留系统状态，帮助理解处置发生的背景。阅读原文。

与当前项目的联系

以下为本站的排查建议：沪漂树洞后端若出现重启，应先比较应用日志、平台事件、退出信息与内存监控的时间线，不把一次异常退出直接认定为 OOM。托管平台上能否读取内核日志取决于权限，缺失证据也要记录。

讨论问题

• 哪些证据来自应用，哪些来自容器或宿主机？
• 如何区分全局内存压力与某个服务达到资源限制？
• 为什么“重启后恢复”不能说明根因已经修复？

建议实验与验收

使用自行编写的日志样本，分别表示应用异常、人工停止和平台报告的内存事件，练习生成事件时间线。样本必须明确标注为模拟，不当作实际事故。报告应列出已知事实、缺失信息和下一步验证，不能仅凭退出码下结论。

这是一份阅读与排查练习，未在生产环境触发 OOM，也未修改内核处置策略。