dmesg -t --follow | grep -i "out of memory|killed process"可实时捕获物理内存耗尽触发的oom事件，需结合memavailable值、/proc/pressure/memory压力指标及swap状态交叉验证，确认是否为全局物理内存不足所致。
直接用 dmesg --follow 配合关键词过滤，就能实时捕获物理内存耗尽触发的 OOM 事件。关键不是等事后翻日志，而是让终端“盯着”内核环缓冲区的每一行新输出。
启用带时间戳的实时流式监控
运行以下命令，终端会持续打印新产生的内核消息，并高亮匹配项：
-
dmesg -T --follow | grep -i "out of memory\|killed process"—— -T 显示本地可读时间，--follow 类似tail -f，保持监听 - 若提示权限不足（如 RHEL/CentOS 8+ 默认限制），先临时放开：
sudo sysctl kernel.dmesg_restrict=0 - 为避免干扰，可加
--level=err,warn过滤掉普通信息：dmesg -T --level=err,warn --follow | grep -i "oom\|kill.*process"
识别物理内存溢出的真实信号
仅靠“Out of memory”字样不够——要确认是物理内存（而非 cgroup 限制或 swap 耗尽）导致的 OOM。重点关注日志中的上下文特征：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 典型物理内存 OOM 行：
Out of memory: Kill process 12345 (java) score 894 or sacrifice child—— 没有Memory cgroup前缀，说明是全局内存不足 - 紧随其后的内存统计行：
Killed process 12345 (java) total-vm:..., anon-rss:...kB, file-rss:...kB—— anon-rss 值高（几 GB 以上）且接近 MemAvailable，表明用户态匿名页占满物理内存 - 配合查看：
watch -n 1 'grep -E "MemAvailable|MemFree" /proc/meminfo'，若 MemAvailable 持续低于 100MB，OOM 风险极高
防止关键日志被覆盖或丢失
内核 ring buffer 容量有限，高频日志可能冲掉 OOM 记录。需主动加固：
- 增大缓冲区：编辑
/etc/default/grub，在GRUB_CMDLINE_LINUX中添加log_buf_len=4M，再运行sudo update-grub && sudo reboot - 落地到文件：确保
rsyslog启用内核日志记录，在/etc/rsyslog.conf中确认有kern.* /var/log/kern.log，然后sudo systemctl restart rsyslog - 紧急时手动保存：一旦发现 OOM 征兆，立即执行
sudo dmesg -T > /tmp/oom-snapshot-$(date +%s).log固化现场
快速验证是否真由物理内存引发
看到 “Killed process” 日志后，别急着调优应用，先交叉验证系统状态：
- 查当前可用内存：
free -h看 available 列是否趋近于 0；cat /proc/meminfo | grep -E "MemAvailable|SwapFree"看是否双低 - 查内存压力：
cat /proc/pressure/memory—— 若 some 字段的 10sec 或 60sec 值长期 > 90%，说明物理内存持续承压 - 排除 swap 干扰：若
swapon --show显示 swap 已关闭，或free -h中 swap 为 0，则 OOM 必定源于物理内存枯竭
