Linux 页缓存（Page Cache）导致内存“假占满”问题分析与优化

欢迎来到蓝队云技术小课堂，每天分享一个技术小知识。

很多运维看到服务器：

free -h

输出：

used 31G

free 200M

第一反应：

内存爆了

但实际上系统依旧运行正常。

这种情况，大概率是：

Page Cache 占用了大量内存

Linux 会把磁盘文件缓存到内存：

Page Cache

目的：

减少磁盘 IO

因为：

内存速度远高于磁盘

查看真实内存：

free -h

重点关注：

buff/cache

available

不是：

free

例如：

Mem:

32G total

31G used

20G buff/cache

说明：

大量内存其实是缓存

并非程序真正占用。

Linux 的核心思想：

空闲内存就是浪费

所以会尽可能缓存文件。

Page Cache 最容易出现在：

· MySQL

· Nginx

· Kafka

· 日志系统

· 大文件读取

场景。

观察缓存详情：

cat /proc/meminfo

重点：

Cached

Buffers

SReclaimable

真正危险的是：

available 很低

例如：

available < 5%

说明系统开始缺内存。

再看缓存命中：

vmstat 1

重点：

si

so

如果：

si/so 持续增长

说明已经发生 swap。

大量 swap 会导致：

系统卡顿

IO 飙升

进程调度变慢

Page Cache 本身不是问题。

真正的问题是：

缓存无法回收

最常见原因：

脏页过多

查看：

cat /proc/meminfo | grep Dirty

如果 Dirty 很大：

说明大量数据未落盘

调整刷盘策略：

sysctl -w vm.dirty_ratio=10

sysctl -w vm.dirty_background_ratio=5

作用：

提前触发刷盘

避免脏页堆积。

另一个关键参数：

sysctl -w vm.swappiness=10

默认：

60

意味着：

系统更积极使用 swap

数据库服务器建议：

swappiness <= 10

减少 swap。

很多人喜欢：

echo 3 > /proc/sys/vm/drop_caches

强制清缓存。

但线上非常危险。

因为：

会导致缓存瞬间失效

引发：

· IO 暴涨

· 数据库抖动

· 响应变慢

真正正确的做法：

观察 available

而不是强制清缓存

数据库场景尤其特殊。

例如 MySQL：

· InnoDB Buffer Pool

· Page Cache

会同时存在。

如果：

Buffer Pool 配置过大

可能挤压系统缓存。

经验值：

MySQL 内存 ≈ 物理内存 60%~70%

给 OS 保留缓存空间。

Kafka 场景更依赖 Page Cache。

因为 Kafka：

顺序读写 + mmap

高度依赖文件缓存。

所以 Kafka 机器：

内存高占用是正常现象

不应随意清缓存。

观察缓存回收：

sar -B 1

重点：

pgscan/s

pgsteal/s

如果持续很高：

说明系统正在频繁回收内存

线上经验：

Linux “内存占满” 很多是假象

真正应该关注的是：

· available

· swap

· IO wait

· page reclaim

而不是：

used

最终建议：

1. 关注 available 而非 free

2. 降低 swappiness

3. 调整 dirty_ratio

4. 不要频繁 drop_caches

5. 给数据库保留 OS Cache

6. 结合 vmstat/sar 分析

Linux 内存管理的核心理念不是：

“留空”

而是：

“尽可能利用缓存提升性能”

蓝队云官网上拥有完善的技术支持库可供参考，大家可自行查阅，更多技术问题，可以直接咨询。同时，蓝队云整理了运维必备的工具包免费分享给大家使用，需要的朋友可以直接咨询。

更多技术知识，蓝队云期待与你一起探索。