真正代表“还能用多少内存”的是 available 列，它是内核估算出可立即分配且不影响性能的内存值；需结合 swap used、sreclaimable、committed_as 等字段综合判断内存压力。

free -h 输出里哪个数字才真正代表“还能用多少内存”

别看 used 那一栏数值高就慌——它包含大量可随时回收的 buff/cache，不是被进程死占着的内存。真正该盯住的是 available 列，它才是内核估算出的、能立刻分配给新进程且不影响性能的内存值。

常见误判场景：

• 看到 used 占了 90%，free 只剩 200MB，但 available 还有 6GB → 实际完全不紧张
• available 持续低于 100MB，同时 Swap 的 used 开始上涨 → 内存真开始吃紧了
• 系统没开 Swap，available 接近 0 且 dmesg | grep -i "killed process" 有输出 → OOM killer 已介入

执行 free -h 后，只关注三行：Mem: 行里的 available，Swap: 行里的 used，以及 Mem: 行末尾的 buff/cache —— 它越大，说明缓存利用越充分，不是坏事。

top 里按内存排序时，为什么 RES 比 %MEM 更可靠

%MEM 是进程占用物理内存占总内存的百分比，但它受系统总内存大小影响，小内存机器上一个 200MB 进程可能显示 15%，大内存机器上同个进程可能只显示 0.5%，无法横向比较。而 RES（Resident Set Size）是进程当前实际驻留在物理内存中的字节数，单位统一，直接反映真实压力。

操作建议：

Zynq Linux Hardware Debug

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

下载

• 运行 top，按 Shift+M（大写 M），按 RES 值降序排列
• 重点关注 RES > 500MB 且长期不释放的进程，尤其是非 java、dockerd、mysqld 等常规服务的进程
• 注意区分：同一共享库（如 libc.so）被多个进程加载时，RES 会重复计算；若需更精确统计，改用 smem -s rss

/proc/meminfo 中哪些字段能帮你定位缓存异常

cat /proc/meminfo 提供比 free 更细粒度的分类，适合排查“明明 available 还行，但系统响应变慢”的情况。关键字段不是 MemFree（它只算完全未分配的内存），而是这几个：

• MemAvailable：和 free 输出一致，仍是第一判断依据
• SReclaimable：slab 分配器中可回收的部分（如 dentry、inode 缓存），若它持续 > 1GB 且 MemAvailable 却很低，可能是文件系统元数据缓存堆积
• PageTables 和 PagetableCache：页表本身占用内存，值过大（> 512MB）可能暗示进程虚拟地址空间碎片化严重或存在内存泄漏
• Committed_AS 与 CommitLimit：前者是内核承诺能分配的内存总量估算，后者是硬上限；若前者接近后者，即使 available 还有余量，也已接近 overcommit 触发点

例如：grep -E "^(MemAvailable|SReclaimable|PageTables|Committed_AS|CommitLimit)" /proc/meminfo 一行查清这几项。

htop 比 top 多出的两个实用功能

htop 不只是配色好看，它在内存分析上确实有实操优势：

• 顶部内存条形图直接显示 Mem 和 Swap 使用比例，一眼识别是否 swap 正在被频繁使用（条变红/黄）
• 按 F5 进入树状视图后，能看清某个主进程（如 python3）下所有子线程/子进程的 RES 分布，避免把父进程当罪魁祸首
• 注意：默认不显示 available，需按 F2 → “Columns” → 添加 MEM_AVAILABLE 字段才能补全关键指标

安装后首次运行前，建议先执行 htop，按 F2 把 MEM_AVAILABLE 加进显示列，否则容易漏掉最核心的判断依据。