最准的物理内存总量是 free -h 的 Mem: 行 total 值，该值为内核运行时上报的实际可用容量，已剔除显存、BIOS/UEFI 预留及固件占用等保留内存。
直接看 free -h 的 Mem: 行就够了
最准的物理内存总量就是 free -h 输出中 Mem: 行的 total 值，比如显示 15Gi，就代表系统当前识别到约 16GB 物理内存。这个值是内核运行时上报的实际可用容量，已剔除显存、BIOS/UEFI 预留、固件占用等保留内存。
剩余“真正能用”的量，不是 free 列，而是 available 列。它综合了空闲页 + 可安全回收的 buff/cache，是内核估算出的应用程序还能申请多少内存而不触发 swap 或 OOM 的关键指标。
- 别信
/proc/meminfo里的MemTotal直接换算值——单位是 KB，且未过滤所有保留区，容易多算几百 MB - 也别用
dmidecode -t memory查插槽标称容量——它只反映硬件插了多少条，不等于系统识别量 - 如果
total比你买的内存条标称小（如 32G 条子只显示 31.2G），大概率是集成显卡或 BIOS 预留了内存，属正常现象
free 各列含义必须分清，否则会误判内存是否紧张
used 不是“真占满”，它不包含 buff/cache；free 是完全空闲的内存，但 Linux 设计上本就不该让它长期维持高位；shared 是 tmpfs 或进程间共享内存页的汇总，多个进程共用一份物理页，不会重复计入 RSS 总和；buff/cache 看似占得多，但绝大部分在内存压力下可被快速回收。
- 典型误操作：看到
used12G、free0.5G 就断定“内存快爆了”——其实available还有 8G，系统完全健康 - 真正危险信号是：
available持续低于 5% 总量，且buff/cache不再增长、swap开始频繁读写 - 监控脚本里建议直接读
/proc/meminfo，字段更全（如MemAvailable、Buffers、Cached），比解析free输出更稳定
为什么不能只靠 top 或 ps 判断系统级内存是否够用
top 和 ps 显示的是进程 RSS（Resident Set Size），即每个进程当前实际占用的物理内存页。但 RSS 加总通常远大于 free 的 total，因为共享内存页（如 libc、共享库、tmpfs）被多个进程重复计算。
-
ps aux --sort=-%mem | head -n 5可快速找出内存大户，但它只告诉你“谁在用”，不回答“系统还剩多少能用” -
top默认按 CPU 排序，需按 M 键切到内存视图，且交互式界面不适合批量采集 - 若发现某进程 RSS 异常高，要进一步用
pmap -x <pid>看其地址空间分布，或查/proc/<pid>/status中的VmRSS和VmSize区分物理与虚拟内存
当 available 接近 0 时，下一步该看什么
available 跌破警戒线，说明内核回收缓存已跟不上内存申请节奏。这时要立刻交叉验证：
- 跑
vmstat 1 5，重点盯si（swap in）、so（swap out）是否持续非零——有换页就说明物理内存真的不够了 - 执行
dmesg -T | grep -i "killed process"，确认 OOM Killer 是否已介入并干掉了进程 - 查
/proc/meminfo中的SReclaimable（可回收 slab 缓存）和Shmem（tmpfs 占用），这两项异常高可能意味着内核缓存或共享内存泄漏
注意：available 是估算值，不同内核版本算法略有差异；它不反映瞬时峰值，单次采样可能漏掉短时 spike，务必结合多次 watch -n 2 free -h 观察趋势。
