journalctl -f -p 3 不是 OOM 预警的可靠方式，因 OOM 关键日志多为 priority=5/6 的内核消息；应使用 sudo journalctl -k -f | grep -i -E "out.of.memory|Killed process" 实时捕获，并结合 /proc/pressure/memory 等指标预判。
journalctl -f -p 3 不是 OOM 预警的可靠方式
OOM（Out of Memory）事件本身不会以 priority=3（err）级别直接写入 journald。内核触发 OOM Killer 的关键日志（如 Killed process、Out of memory: Kill process）通常由 kern 子系统生成，记录在内核环形缓冲区（dmesg），再由 journald 收集为 priority=6（info）或 priority=5（notice） 的内核消息。用 -p 3 过滤会漏掉绝大多数真实 OOM 日志。
真正有效的实时监控需聚焦内核消息 + 关键关键词 + 合理优先级范围。
✅ 正确做法：用 -k 和关键词组合实时捕获 OOM 信号
-k（等价于 --dmesg）确保只查内核日志，这是 OOM 杀进程的唯一权威来源。配合 grep 精准匹配，比依赖日志级别更可靠：
sudo journalctl -k -f | grep -i -E "out.of.memory|oom_kill_process|Killed process|memory:.*exhausted"
这个命令会：
- 实时输出新产生的内核日志（
-k -f） - 只显示含 OOM 相关关键词的行（大小写不敏感，支持常见变体）
- 立即看到被杀进程名、PID、内存分配上下文等关键信息
✅ 补充：加时间戳和高亮提升可读性
日常排查时建议增强可读性：
sudo journalctl -k -f --output=short-iso | grep -i --color=always -E "out.of.memory|oom_kill_process|Killed process"
-
--output=short-iso显示 ISO 格式时间（如2026-05-06 13:42:18），便于定位发生时刻 -
--color=always让关键词高亮，一眼识别重点
✅ 进阶：结合内存压力指标预判 OOM（非事后，而是预警）
真正“预警”不是等 OOM 发生，而是监控即将触发前的征兆：
-
查看内存压力（pressure stall information）：
watch -n 1 'cat /proc/pressure/memory | grep -E "some|full"'
当
some avg10=10.00持续 >5 或full avg10=1.00出现，说明系统已严重争抢内存，OOM 很可能在几分钟内发生。 -
观察页面分配失败（allocstall）：
watch -n 1 'grep allocstall /proc/vmstat'
数值每秒明显上涨（如从 1000 → 1500 → 2200），代表内核频繁尝试回收内存但失败，是 OOM 的强前兆。
⚠️ 注意：不要依赖 -p err 或 -p warning
- 内核 OOM 日志极少打到
err（priority=3）或更高； -
warning（priority=4）也不稳定，很多发行版默认不将 OOM 归为此类； - 单纯
journalctl -f -p 3可能全程静默，让你误以为系统安全，实则 OOM 已悄然发生。
靠关键词 + -k + 压力指标，才能既捕获已发生的 OOM，又提前感知内存危机。
