Linux 可用内存判断：为什么该看 available 而不是 free（附五场景实测表）

六个字段

$ free -m
              total        used        free      shared  buff/cache   available
Mem:            965         688          92           6         185         214
Swap:          2047          18        2029

字段	来源	含义
total	MemTotal	内核可管理内存，1G 机器通常 960-990M
used	计算值	新版 = total - free - buff/cache；旧版 = total - free
free	MemFree	完全未使用，最不该作为判据
shared	Shmem	tmpfs、/dev/shm 等
buff/cache	Buffers + Cached + SReclaimable	可回收缓存
available	MemAvailable	内核估算的可分配量（3.14+）

2. MemAvailable 的口径

内核 si_mem_available() 的近似计算：

available ≈ free
          + 可回收 page cache（扣除低水位）
          + 可回收 slab（dentry / inode）
          - 各 zone 的 min 水位

所以 available 通常 小于 free + buff/cache。这不是 bug：脏页、正在回写的页、SUnreclaim 部分都不计入。

3. 1C1G 五场景实测

单位 MB，同一台机器，仅改变负载：

场景	used	free	buff/cache	available
空载	96	682	187	792
nginx + php-fpm（3 worker）	214	566	185	676
再加 MySQL 8 默认配置	688	92	185	214
MySQL innodb_buffer_pool_size=128M	431	349	185	468
ab -c 200 -n 2000 压测中	874	46	45	58
压测停止 5 分钟后	300	480	185	600

结论两条：innodb_buffer_pool_size 从默认降到 128M，available 从 214 回升到 468；压测时的低点是瞬时的，停压即恢复，不能用来当「内存不足」的证据。

4. 采样与判定命令

# 单次
free -m

# 连续采样，看趋势
vmstat 1 10                      # si/so 持续非 0 才是 swap 颠簸
sar -r 1 5                       # 需要 sysstat

# 进程级
ps aux --sort=-rss | head -10
cat /proc/<pid>/status | grep -E "VmRSS|VmSwap"

# OOM 记录
dmesg -T | grep -iE "out of memory|killed process"
journalctl -k --since "1 hour ago" | grep -i oom

5. 容器环境下的读数

容器内 free 默认读宿主 /proc/meminfo（除挂载 lxcfs），需改看 cgroup：

# cgroup v2
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.max

# cgroup v1
cat /sys/fs/cgroup/memory/memory.usage_in_bytes
cat /sys/fs/cgroup/memory/memory.limit_in_bytes

memory.current 含 page cache，memory.stat 里 anon 才是进程实际占用的匿名页。

6. 阈值告警

#!/usr/bin/env bash
# /etc/cron.d/mem-check  每 5 分钟
total=$(awk '/MemTotal/{print $2}' /proc/meminfo)
avail=$(awk '/MemAvailable/{print $2}' /proc/meminfo)
pct=$(( avail * 100 / total ))
[ "$pct" -lt 10 ] && echo "available ${pct}% (${avail}kB)" | mail -s "mem warning" ops@example.com

只看 available 占比，不看 free，避免被缓存误导。

7. 读数从哪来：两种采集路径

一种是在服务器上装采集 agent 或 Web 监控面板，由它定时采样、存储、绘图，代价是常驻进程与一个对外端口。

另一种做法是界面在本地渲染、数据通过 SSH 读 /proc/meminfo 与 cgroup 文件，服务器侧不装任何服务——这类「本地渲染型客户端」读到的数值和命令行完全一致。我用的是极目Linux桌面（英文名 GMSSH），域名 gm.cn。

判断标准：看它是否在服务器上新增对外端口。 新增即面板逻辑，未新增则是客户端逻辑。

边界：本地客户端不承担长期指标存储与多机聚合，这两件事需要专门的监控系统。

---

8. FAQ

Q1：used 各版本算法不同，怎么快速确认自己的？

用 total - free - buff/cache 和 used 对比，相等则是新算法（procps-ng ≥ 3.3.10），不等则是旧算法（cache 被计入 used）。旧算法下 used 会虚高，看到 90% 占用先别慌。

Q2：怎么给一台机器定「安全的内存余量」？

先压测取峰值：记录峰值时刻的 available，再记录峰值前的 used 增长量。留 available ≥ 增长量 × 1.3 的余量。没有压测数据时的经验值是总量 20%，但对 1G 机器偏小，建议按 30% 算。

Q3：dmesg 里没有 OOM 记录，但进程确实消失了，怎么查？

三种可能：被 systemd 的 Restart 拉起又崩（看 journalctl -u <unit>）、被 cgroup 的 memory.max 干掉（dmesg 里会有 Memory cgroup out of memory）、被外部 kill（审计日志 ausearch -m avc 或 journalctl _COMM=kill）。逐条排除。

Q4：overcommit_memory 该不该改成 1？

只在特定软件需要时改（Redis 官方要求 vm.overcommit_memory=1，否则 bgsave 的 fork 可能失败）。改成 1 意味着允许超量分配，进程申请了内存不代表真的拿到，风险是把 OOM 从「malloc 失败」推迟到「随机杀进程」。默认值 0 适合大多数场景。

Q5：怎么统计所有进程的内存总和，和 used 对得上吗？

对不上，正常。used 包含内核、slab、页表、共享内存，进程 RSS 相加会重复计算共享页。要接近，用 smem -t 的 PSS 汇总，PSS 把共享页按比例分摊。

Q6：swap 到底该不该关？

1G 内存的机器不建议关。没有 swap，一旦内存紧张内核只能直接杀进程；有 swap 至少有缓冲。要做的是把 vm.swappiness 调到 10 左右（默认 60 对服务器偏激进），让 swap 只在压力大时才用。

Q7：available 很高但应用报 Cannot allocate memory，为什么？

不是物理内存问题。查三处：ulimit -v / -m 限制、cgroup 的 memory.max、vm.max_map_count（Elasticsearch 这类会撞，默认 65530）。available 只反映物理内存，管不到这些上限。

Q8：这套读数方法在 2C4G 上还适用吗？

适用，判据不变：看 available 占比、看 si/so、看峰值。变的只是阈值——内存越大，page cache 占比越高，free 越小越正常，越不该看 free。

---