OOM 时是否崩溃
vm.panic_on_oom 决定物理内存耗尽时内核的处置方式：默认值 0 启用内存不足杀手，由它挑选并终止一个进程来释放内存，系统本身继续运行；设为 1 则直接让内核崩溃，配合 kernel.panic 的自动重启就变成整机重启。取值 2 只在特定约束场景下触发崩溃。选择哪种行为，本质是在「牺牲一个进程保住系统」和「重启整机避免状态不确定」之间做取舍。
基本信息
| 参数 | vm.panic_on_oom |
|---|---|
| 取值 | 0 启用内存不足杀手（默认） / 1 内存耗尽时崩溃 / 2 特定约束场景下崩溃 |
| 排查入口 | dmesg 中的内存不足记录与被终止进程信息 |
| 配套参数 | kernel.panic 决定崩溃后多久自动重启 |
| 进程保护 | 可通过评分调整参数降低关键进程被选中的概率 |
| 适用建议 | 常规业务保持默认，无人值守设备可评估崩溃重启策略 |
典型使用场景
- 排查服务被杀死：确认是内存不足杀手所为而非进程崩溃
- 定位内存消耗方：从内核记录中还原当时的内存分布与牺牲进程
- 保护关键进程：通过评分调整降低核心服务被优先选中的概率
- 无人值守环境：评估崩溃自动重启与业务可用性的取舍
- 容量排查：反复出现内存不足说明存在泄漏或配置不合理
查看与排查
查看与排查
sysctl vm.panic_on_oom # 读当前策略
dmesg -T | grep -i -E 'oom|killed process' | tail -20 # 查看内存不足记录
journalctl -k | grep -i oom | tail # systemd 系统上的等价查法
sysctl kernel.panic # 崩溃后的重启行为
cat /proc/<pid>/oom_score 2>/dev/null # 单进程被选中的评分
ps -eo pid,rss,comm --sort=-rss | head # 内存占用排行取值与后果
| 取值 | 行为 | 适用与代价 |
|---|---|---|
| 0 | 终止一个进程释放内存 | 通用默认，系统继续提供服务 |
| 1 | 内核崩溃，可能重启整机 | 无人值守设备可用，会丢失所有内存中的现场 |
| 2 | 特定约束场景下崩溃 | 仅在特定内存约束条件下生效，需查内核文档 |
| 评分调整 | 降低指定进程被选中的概率 | 保护关键进程，但不能替代容量治理 |
设为 1 后内存耗尽会导致整机不可用；如果同时配置了崩溃自动重启，表现就是节点不定期重启，业务会承受比终止单个进程更长的中断时间。启用前必须确认可用性策略与现场采集手段。
排查内存不足问题一定要看内核记录的完整段落：里面包含内存分布、进程内存占用与最终被终止的进程。只看监控告警会漏掉根因，也无法判断是应用泄漏还是整体容量不足。