一、为什么内存“总是”被占满？——Linux 的缓存哲学
Linux 内核有一条核心设计原则：空闲内存是浪费的资源。只要物理内存（RAM）没有被应用明确申请走，内核就会把它用来缓存磁盘上的数据。
这部分缓存主要分为两类，合称 buff/cache：
- Buffer（缓冲区）： 缓存文件系统的元数据（如 inode、目录结构）和块设备的原始写入。通常占用很小。
- Page Cache（页缓存）： 这是真正的大头。任何通过
read()、mmap() 访问过的文件内容，都会被缓存在未使用的内存页中。程序代码、配置文件、日志、数据库数据文件等全在这里。
你看到的高内存占用，绝大多数就是 Page Cache。
它的意义在于：下一次读写同样的文件时，直接命中内存，速度比磁盘快几个数量级。当应用程序需要新内存时，内核会瞬间丢弃一部分不活跃的缓存页，腾出空间给应用，这个过程对应用几乎无感。
因此，传统意义上“已用内存 = 总内存 - 空闲内存”的公式在 Linux 下是错误的。真正的公式是：
已提交给进程不可回收的内存 ≈ 总内存 - 真正可用内存(available)
二、关键数据结构和回收机制
要深入理解，需要知道内核是如何管理内存页的。
1. 内存页的两大家族
- 匿名页（Anonymous Pages）： 进程的堆、栈、mmap 的 MAP_ANONYMOUS 区域等，没有对应磁盘文件。需要换出时只能写入 Swap。
- 文件页（File-backed Pages）： 可执行文件、普通数据文件的缓存，有磁盘文件作为后备。回收时，干净的页可以直接丢弃；脏页（被修改过）得先写回磁盘。
2. 活跃/非活跃链表（LRU）
内核为每个内存区域维护两个链表：
- Active list： 最近被访问过的页，属于“热”数据。
- Inactive list： 一段时间没被访问的页，属于回收的候选者。
当内存紧张时，kswapd 线程会扫描 Inactive 链表，回收干净的文件页，或者将脏页写回后回收。如果压力极大，连 Active 链表里的页也会被降级到 Inactive 然后回收。
3. 水位线（Watermark）
内核为每个内存区域设定了三条水位线：min、low、high。当空闲内存降到 low 以下时，会唤醒 kswapd 守护线程在后台异步回收内存，直到回到 high 以上。如果空闲内存直接击穿 min 线，那么任何申请内存的操作都会被阻塞，并触发直接内存回收（Direct Reclaim），此时进程会卡顿，IO 飙升，这就是明显的内存压力。
4. Swap 与 swappiness
当需要回收匿名页时，内核要么把它们换出到 Swap 分区/文件，要么就不能回收。vm.swappiness（范围0-100）参数控制内核回收文件页 vs. 换出匿名页的倾向：
- 值越低，越倾向于回收文件页（清缓存），保留匿名页。
三、正确解读内存状态的核心工具
1. free -h 命令——第一道防线
total used free shared buff/cache available
Mem: 15Gi 3.2Gi 500Mi 1.8Gi 11Gi 9.8Gi
Swap: 2.0Gi 100Mi 1.9Gi
- total： 物理内存总量。
- used： 已使用，计算公式大致是
total - free - buff/cache。这个值高是正常的。 - free： 完全没有被使用的内存，数字小是常态。
- shared： 大部分是
tmpfs 占用的内存（如 /dev/shm），进程间共享内存也计入这里。 - buff/cache： 就是上面说的 Buffer 和 Page Cache。可以随时回收。
- available： 这是唯一需要你关心的数字。它由内核估算，表示即使现在需要，能立即分配给新进程而不导致 OOM 的可用内存。它近似等于
free + 可立即回收的buff/cache。
判断标准：只要 available 足够你将要运行的任务使用，且系统响应流畅，内存使用率 99% 也毫无问题。
2. /proc/meminfo——显微镜
这是 free 的数据来源，关键字段：
- MemAvailable： 和
free -h 里的 available 一致，是决策核心。 - Cached： Page Cache 总大小，包含文件缓存和 tmpfs。
- SwapCached： 曾经被换出，但又被换入内存，同时 Swap 中仍保留副本的页。如果这个值很大且波动，说明系统正发生频繁的换入/换出。
- Committed_AS： 系统承诺给所有进程的内存总量（虚拟内存总和）。如果它超过了
CommitLimit（物理内存+Swap），一旦所有进程同时要求兑现承诺，就会触发 OOM Killer。 这可以预警内存超卖。 - Shmem： 共享内存和 tmpfs 占用的总量。如果异常大，说明可能有进程在
/dev/shm 里创建了大量文件。 - Active(file) /
Inactive(file)：活跃/非活跃的文件缓存页。你可以看到缓存中有多少是热的。
3. vmstat 1——实时压力监控
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 10240 51200 200 11500000 0 0 0 3 1 1 5 1 94 0 0
关键列：
- si / so： swap in 和 swap out 的速率（KB/s）。如果这两列持续不为 0，说明系统正在严重抖动，内存已严重不足。
- bi / bo： 块设备读/写速率。
- r： 运行队列长度；b：不可中断睡眠的进程数。如果
b 持续大于 0，通常意味着 IO 阻塞，可能是内存不足导致的直接回收在闪存/磁盘上。
四、完整的内存健康度判断流程
第一步：看症状
- 系统响应变慢、应用延迟飙升、大量磁盘 IO 声音。
- top 或
htop 中看到 CPU 等待 IO 的 wa 占比很高，或者 kswapd0 进程 CPU 占用率异常。 - 查看系统日志：
dmesg | grep -i oom，如果出现 “Out of memory: Killed process”，说明已经触发过 OOM Killer。
第二步：查 available 和 swap
- free -h 观察
available - swap 的
used 很高且 si/so 速率很高，问题严重；如果只是用了少量 Swap 但 si/so 几乎为 0，可能是因为某个非活跃匿名页被换出过一次，可以接受。
第三步：用 top / htop 找“凶手”
- 重点关注
RES（物理内存非换出部分）和 SHR（共享内存）。如果某个进程的 RES 在长时间内只增不减，很可能存在内存泄漏。 - 用
smem -rs pss 可以看到 PSS（比例集大小），它能更公平地反映进程间共享内存的实际开销。
第四步：深挖缓存来源（当缓存异常大时）
- 如果你怀疑是文件缓存太大导致
available 过低，可以查看具体是什么文件占用了缓存。虽然内核不直接提供完整列表，但可以通过工具如 vmtouch、pcstat 或 fincore 查看某个文件或目录的缓存占用。 - 检查
tmpfs 占用：df -hT | grep tmpfs，看 /dev/shm 或 /run 是否被写入了大量文件。
第五步：监控内存回收事件
- cat /proc/vmstat | grep -E "pgsteal_|pgscan_|allocstall"
- pgsteal_kswapd 和
pgscan_kswapd - allocstall： 发生直接内存回收的次数。如果这个数字不断增长，说明空闲内存多次击穿 min 水位线，内存严重不足。
五、经典场景分析
1. “我有 32GB 内存，数据库占了 28GB，available 只有 100MB，是不是要爆了？”
不一定。 数据库（如 MySQL、MongoDB）通常会故意将自己的 buffer pool 锁定在内存中，它们调用的是 malloc 获取匿名页，这部分内存被计为 used，几乎不会被回收。同时，系统通常还会有大量文件缓存。如果 available 非常小，但系统没有 swap 换入换出、没有直接回收、kswapd 也不忙，说明内存分配已经“刚好够用”，处于平衡态。但如果业务一个尖峰需要更多内存，可能立刻 OOM。你需要预留一定量的 available 作为缓冲。
2. “Swap 用了一点，但系统不卡，要不要管？”
可以不管。比如一个后台服务启动了但长期没请求，它的部分内存页被换出到 Swap，这是内核的优化策略，不干扰活跃进程。只有当 vmstat 的 si 列持续有数值，说明进程正被频繁换入，这才会影响性能。
3. “available 很大，但 cached 非常高，应用程序却说自己内存不足”
应用程序可能不是在物理内存层面失败，而是触及了虚拟内存限制（如 ulimit -v）或 cgroup 的内存上限。需要检查容器/进程的 cgroup 限制，而不是宿主机全局内存。
六、如果确实是内存压力过大，怎么办？
不要随手 echo 3 > /proc/sys/vm/drop_caches。这只会暂时清空缓存，性能会陡降，随后缓存又会重新填充，治标不治本，而且可能掩盖真正的内存泄漏。
正确应对：
- 调整应用参数： 降低数据库 buffer pool、Java heap size、缓存大小等。
- 控制超卖： 用 cgroup (v1/v2) 给服务设置内存限制，避免单个应用拖垮全局。
- 调优参数： 适当降低
vm.swappiness（如设为 10），让内核优先清缓存，尽可能保留匿名页，减少 Swap 颠簸。 - 开启 zram/zswap： 在内存中压缩一部分交换数据，用 CPU 换 IO，对内存压力有奇效。
- 加物理内存： 这是最简单的终极方案。
