free -h 的 Mem: 行 total 值即为当前系统实际识别并可用的物理内存总量，它由内核实时上报，已剔除显存、固件保留区、PCIe BAR 等不可用区域，单位 GiB，无需换算，最准确可靠。
直接看 free -h 输出中 Mem: 行的 total 值，就是当前系统实际识别并可用的物理内存总量。
为什么 free -h 的 total 最可靠
这个值来自内核运行时内存管理器的实时上报，已自动剔除显存、固件保留区、PCIe BAR 空间等不可用区域。它不是理论插槽容量，也不是原始硬件描述，而是“此刻真能拿来跑程序”的内存上限。
-
/proc/meminfo中的MemTotal单位是 KB，需手动除以1024²才能得到 GiB，且部分 ARM 或嵌入式平台可能包含 BIOS 未启用的内存块 -
dmidecode -t memory显示的是 SMBIOS 表记录的硬件配置，比如插了两根 16GB，但若一根接触不良或 BIOS 关闭通道，free -h仍只报 16Gi -
lshw和lsmem引入额外抽象层，字段含义模糊，容器或 initramfs 环境中常缺失依赖（如 udev/dbus） -
/dev/mem是原始设备文件，读取危险、无结构、需 root 权限，完全不适用于查总量
free -h 输出里哪些字段别混淆
Mem: 行的四个关键字段容易误读：
-
total：物理内存总量——你要的答案 -
used：内核统计的“已分配”量，含缓存/缓冲，≠ 实际被进程独占的内存 -
free：完全未分配的空闲页，通常极小，不能代表“还能用多少” -
available：估算的可立即用于新进程的内存，考虑了可回收缓存，但它不是总量
例如输出 Mem: 15Gi 6.5Gi 2.3Gi ... available 7.4Gi，总量就是 15Gi，不是 7.4Gi，更不是 2.3Gi。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
看到 total 比标称小，大概率不是命令错了
比如主板标 32GB，free -h 却显示 31.2Gi，常见原因有：
- BIOS 预留内存（如开启 CSM 或安全启动时）
- 集成显卡占用（尤其在服务器 BIOS 中启用了 iGPU）
- UEFI 运行时服务或 ACPI 表占用固定区域
- 内核启动参数中设置了
mem=限制（检查cat /proc/cmdline）
这种偏差是正常现象，free -h 的 total 仍是当前运行环境下的真实可用上限。
真正要确认“物理内存总量”，盯死 free -h 的 Mem: → total。其他命令要么要换算，要么反映的是不同层级的信息，容易引入歧义。
