linux中无统一“内存利用率”字段，free命令不直接显示该值；正确判断依据是available是否充足，而非used/total比值。
free 命令输出里没有“内存利用率”这个字段
Linux 没有定义统一的「内存利用率」百分比，free 本身也不计算或显示它。很多人误把 used / total * 100% 当作利用率，但这是错误的——因为 used 包含大量可回收的 buff/cache，把它当“已占用”会严重高估压力。
真正有意义的判断依据是：available 是否充足。只要 available > 10% total（或绝对值 > 500MB），通常就不构成瓶颈；若 available 持续 Swap used 上升，才说明内存紧张。
常见错误现象：
- 看到
used占了 90%，立刻怀疑内存泄漏，实际available还有 3GB - 监控脚本硬套
(used / total) * 100告警，结果频繁误报 - 忽略
Swap行，直到si/so暴涨、系统卡顿才反应过来
为什么不能用 used / total 计算“利用率”
used 的定义是：total - free - buffers - cached（旧内核）或更宽泛的“内核视角下当前标记为 in-use 的页”，但它混入了大量临时性、可驱逐的内容，比如：
-
page cache：刚读过的文件块，下次再读直接命中，不用 IO -
dentries/inodes：目录项和索引节点缓存，slabtop里常占几百 MB -
tmpfs内存文件系统内容，算在shared里，但也是可回收的
这些都不是“被进程长期锁住”的内存。Linux 的设计哲学是“空闲内存就是浪费的内存”，所以 used 高反而是健康信号——前提是 available 不掉。
性能影响上：强行清空 buff/cache（如 echo 3 > /proc/sys/vm/drop_caches）会导致后续文件读写变慢，得不偿失。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
如何安全地估算真实内存压力
不要自己造公式。直接看 free -h 输出中三处联动指标：
-
Mem: available—— 主要参考值，低于 5% 要警惕 -
Swap: used—— 非零即危险，尤其当available同步走低时 -
buff/cache大小 + 变化趋势 —— 如果它很大但available很小，可能是脏页积压（vmstat 1看bi和wa）或内核无法及时回收（如某些 NFS 场景）
实操建议：
- 用
free -h -s 2 -c 10抓 10 次快照，观察available波动是否收敛 - 配合
vmstat 1 5看si（swap in）和so（swap out）是否 > 0 - 查具体进程时，用
ps aux --sort=-%mem | head -10，但注意%MEM是 RSS/total，不是 PSS，对共享库多的进程会高估
哪些场景下你必须跳过 free 直接看 /proc/meminfo
free 是摘要，/proc/meminfo 是源头。当出现以下情况，free 已不够用：
-
available异常偏低，但buff/cache并不大 → 查SReclaimable（可回收 slab）、Shmem（tmpfs 占用）、PageTables（页表膨胀） - 怀疑内核内存泄漏 → 对比
Slab和SReclaimable差值，再用slabtop定位对象 - 容器环境或 cgroup 限制内存 →
free显示的是宿主机全局视图，需进对应 cgroup 目录看memory.usage_in_bytes
例如：grep -E "^(Mem|SReclaimable|Shmem|PageTables)" /proc/meminfo 能快速筛出关键项。
最容易被忽略的一点：available 的估算依赖内核版本。4.5+ 内核才引入较准的 watermark-based 算法；老内核（如 RHEL6）的 available 是粗略估算，此时更要交叉验证 vmstat 和 /proc/meminfo。
