物理内存不足会拖慢程序响应，需关注available值是否低于总内存5%～10%、res异常进程及dmesg中oom killer记录。

物理内存不足会直接拖慢程序响应，因为系统被迫频繁换页、启用 Swap，甚至触发 OOM Killer 杀进程。排查关键不是看“用了多少”，而是看“还能不能给新任务分配内存”。下面分三步快速定位问题：

看 available 内存是否告急

运行 free -h，重点关注 available 这一列：

• available 值低于总内存的 5%～10%，说明真正可用内存已严重不足；
• 即使 free 列还有几百 MB，但 available 很低，程序仍可能卡顿——因为 buff/cache 中部分数据无法立即回收；
• 如果 Swap 的 used 持续增长（尤其 >50%），说明物理内存长期不够用，系统已在透支磁盘空间。

找谁在吃掉真实内存（RES 而非 VIRT）

用 ps aux --sort=-%mem | head -n 10 或 top → 按 Shift+M 排序，重点看：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• RES（常驻内存）：进程当前实际占用的物理内存大小，比 VIRT 更反映真实压力；
• 同一服务多个实例（如 Java 多个 -Xmx 设置过高）、未释放连接的数据库客户端、缓存未限容的 Redis/Node.js 进程，都容易 RES 突增；
• 留意 RSS 持续缓慢上涨的进程——可能是内存泄漏，需结合日志和重启后是否复现判断。

确认是否被 OOM Killer 干掉过

检查内核是否已出手干预：

• 执行 dmesg -T | grep -i "killed process"，查看最近是否有进程被杀；
• 翻 /var/log/messages 或 /var/log/syslog，搜索 "Out of memory" 或 "oom-killer"；
• 若发现某服务反复在内存紧张时段退出，且日志中明确写出 “Killed process XXX (xxx)”，基本可锁定是物理内存不足导致的被动终止。

不复杂但容易忽略：很多响应慢不是 CPU 不够，而是内存不够导致进程反复等待页加载或被调度延迟。盯住 available 和 RES，再交叉验证 dmesg，90% 的物理内存瓶颈能当天定位。