Drop Caches

在所有 Linux 服务器上每天定时执行一次以下命令，是否可行？有什么利弊？

sync;sync;sync;sync;sync;sync;sync;sync;sync;sync
echo 1 > /proc/sys/vm/drop_caches

结论先行（一句话版）

不建议在所有 Linux 服务器上每天定时执行 sync; echo 1 > /proc/sys/vm/drop_caches，它不是“优化”，而是一次“人为制造的冷启动 I/O 抖动”，只有在极少数排障或测试场景才有价值。

下面给你工程级、可落地的分析。

一、这两条命令到底做了什么（澄清一个常见误解）

1️⃣ `sync`（你执行了 10 次）

sync

作用：

将 脏页（dirty pages） 刷写到磁盘
是一个 阻塞调用
多次执行 ≈ 一次执行

📌 结论：

sync;sync;sync;... 在现代 Linux 内核中 没有任何额外收益

2️⃣ `echo 1 > /proc/sys/vm/drop_caches`

echo 1 > /proc/sys/vm/drop_caches

作用：

释放 Page Cache（文件缓存）
不会释放：
- 应用内存
- 匿名页
- 数据库 Buffer / Shared Memory

等价于：

告诉内核：刚才缓存的文件数据，全部忘掉

二、每天定时执行，会发生什么？

✅ 能得到的“表面效果”

现象	说明
`free -h` 中 buff/cache 下降	看起来“内存变多了”
某些人感觉系统“清爽”	心理安慰
排障时可模拟冷缓存	测试用途

❌ 真正的代价（非常关键）

1️⃣ 制造 I/O 风暴（最严重）

所有文件缓存被清空
下一次访问：
- 数据库数据
- Python 程序依赖
- ELF / so
- 配置文件

👉 全部重新从磁盘读取

📌 后果：

磁盘 IOPS 暴涨
延迟瞬间升高
SSD 写放大、HDD 抖动

2️⃣ 数据库是“直接受害者”

PostgreSQL / MySQL 场景

类型	影响
PostgreSQL	OS Page Cache 是 shared_buffers 的“二级缓存”
MySQL InnoDB	即使有 buffer pool，也高度依赖 OS readahead

结果：

QPS 下降、慢查询飙升、checkpoint 压力变大

3️⃣ 破坏内核的“自适应内存管理”

Linux 的内存管理原则是：

空闲内存 = 浪费内存

内核会：

自动回收 cache
根据压力动态调整
优先回收“可重建”的 cache

你这个命令是：

强行干预内核的 LRU / reclaim 逻辑

4️⃣ 容器 / 虚拟化环境尤其危险

Page Cache 是 宿主机共享的
你清的是：
- 所有容器
- 所有虚拟机进程
- 所有服务的 cache

👉 一个 cron，拖慢整台宿主机

三、什么时候“可以”用？

✅ 合理使用场景（极少）

场景	是否合理
性能基准测试（冷缓存）	✅
内存泄漏排障	⚠️ 临时
内核/FS 行为验证	✅
DBA 手动维护窗口	⚠️

前提：

人工执行
有明确目的
有维护窗口

四、什么时候“绝对不该用”？

❌ 生产环境定时任务

❌ 数据库服务器

❌ 高并发应用服务器

❌ K8s / Docker 宿主机

❌ SSD / NVMe 寿命敏感环境

五、正确的替代方案（你真正想解决的问题）

你“想定期清 cache”，本质通常是想解决这些👇

🎯 目标 1：防止 OOM

正确做法：

vm.swappiness = 1
vm.vfs_cache_pressure = 100
vm.overcommit_memory = 2

👉 让内核 按规则回收 cache，而不是暴力清空

🎯 目标 2：避免脏页堆积

vm.dirty_background_ratio = 5
vm.dirty_ratio = 15
vm.dirty_expire_centisecs = 3000

👉 平滑写盘，而不是 sync 洪峰

🎯 目标 3：观测内存，而不是“清理”

vmstat 1
sar -B 1

六、如果你一定要保留类似行为（不推荐，但给你工程级安全方案）

✅ 最低伤害版本

sync
echo 2 > /proc/sys/vm/drop_caches

2：只释放 dentry / inode cache
不清 Page Cache
风险小很多

📌 但仍不建议定时执行

七、最终总结（给你一个可以写进规范的话）

Linux 的 Page Cache 是性能组件，不是垃圾；定时清理缓存不是优化，而是破坏内核内存管理的行为，只应在特定排障或测试场景下人工使用。