Linux 清理缓存详解

在 Linux 服务器运维里，buff/cache 越跑越高是常态，很多运维和数字化采购同学会把它当成内存告急的信号。本文围绕 /proc/sys/vm/drop_caches 这个接口，讲清楚 PageCache、Dentries、Inodes 三类缓存分别是什么、echo 1/2/3 各释放哪些内容、为什么清理前要先 sync，以及 free -m 怎么读。对自建服务器、IDC 托管和云主机成本敏感的企业运维团队，这些细节直接影响业务稳定性和采购判断。

核心观点

Linux 的 drop_caches 只是把可回收的缓存交还给系统，并不会终止任何运行中的进程，也不会丢数据；真正需要警惕的是清理前没做 sync，以及把清理缓存当成解决内存不足的常规手段。

先搞懂三类缓存，再决定要不要清

Linux 的缓存不是一块铁板，拆开看主要有三种，各自服务不同的 I/O 路径：

• PageCache（页面缓存）：缓存磁盘文件的数据块，加速读取。数据库、Web 静态文件、日志读取都吃它。
• Dentries（目录缓存）：缓存目录结构，提升文件系统路径查找效率。
• Inodes（索引节点缓存）：缓存文件元数据（权限、大小、时间戳等），加快文件访问。

我自己的经验是，绝大多数“内存不够”的告警其实来自 PageCache 的正常增长，而不是真的内存泄漏。判断前先看 available 这一列，它才是系统认为还能给新进程用的量。

清理缓存的三种模式与命令

Linux 通过 /proc/sys/vm/drop_caches 提供手动释放缓存的入口，写入不同数字对应不同范围：

仅释放 PageCache：

echo 1 > /proc/sys/vm/drop_caches

释放 Dentries 和 Inodes：

echo 2 > /proc/sys/vm/drop_caches

释放所有缓存（PageCache + Dentries + Inodes）：

echo 3 > /proc/sys/vm/drop_caches

⚠️ 这里提醒一句：drop_caches 只是释放缓存，数据仍保留在内存中，不会影响运行中的进程。所以它不会“杀掉”你的 MySQL 或 Nginx，但也别指望它解决 OOM。

为什么清理前一定要先 sync

直接 drop 缓存，理论上存在脏页尚未落盘就被回收的风险。稳妥做法是先执行 sync，把缓存数据同步到磁盘，再清理：

sync && echo 3 > /proc/sys/vm/drop_caches

sync 的作用是把所有缓存数据同步到磁盘，避免因清理缓存导致数据丢失。生产环境建议把这两条写进脚本而不是手敲，减少误操作。

用 free -m 验证清理效果

清理前后对比，最直观的是 free -m：

free -m

示例输出：

              total        used        free      shared  buff/cache   available
Mem:          16000        8000        2000        1000        6000        5000
Swap:          8000         100         7900

buff/cache 代表缓存占用的内存，执行清理缓存后应看到此数值减少。但要注意，free 列上升不代表业务变快，反而可能让下一次读盘变慢——缓存被清空后，热数据要重新从磁盘加载。

适用场景与选型建议

什么时候该清、什么时候不该清，直接决定你是在优化还是自找麻烦：

• 适合清理：做内存基准测试、压测前需要干净环境、临时排查缓存相关异常、容器/虚拟机内存统计需要对齐。
• 不建议清理：日常运维中因为 buff/cache 高就反复 echo 3。缓存本来就是拿来用的，频繁清空会拖慢 I/O，属于典型的“指标好看、性能变差”。
• 替代思路：真正内存吃紧，优先查进程 RSS、调 vm.swappiness、加内存或做服务拆分，而不是靠 drop_caches 续命。
• 采购视角：如果一台 16GB 的云主机长期 available 偏低，问题在业务内存占用而非缓存，选型时应按实际工作集估算规格，而不是按 free 的瞬时值加配。

关键信息

• 缓存接口路径：/proc/sys/vm/drop_caches，写入 1/2/3 分别对应不同释放范围。
• 三类缓存：PageCache（磁盘数据）、Dentries（目录结构）、Inodes（文件元数据）。
• 清理前执行 sync，确保脏页落盘，降低数据丢失风险。
• 用 free -m 观察 buff/cache 变化，available 比 free 更能反映真实可用内存。

qidao123.com企服评测-应用市场 编辑提示

drop_caches 是排查和测试工具，不是日常运维的省内存手段。选服务器或云主机时，别被 buff/cache 高吓到，先看 available 和业务实际工作集再决定是否加配。

标题：Linux 清理缓存实战：drop_caches 参数与 crontab 定时回收

服务器跑久了内存被缓存吃满，是很多运维和数字化采购同学都会遇到的场景。这篇接着上一段，重点聊两件实操的事：怎么用 crontab 让 Linux 自动定期清理缓存，以及 echo 1/2/3 这几个参数到底释放了什么。如果你正在做服务器选型或者负责 ToB 系统的稳定性，这套回收策略值得先摸清楚再上生产。

自动定期清理缓存：crontab 怎么写

如果确实有必要定期清理缓存，可以用 crontab 定时任务来做。先打开编辑：

crontab -e

然后添加下面这条定时任务，含义是每天凌晨 2 点清理所有缓存：

0 2 * * * sync &&

echo 3 > /proc/sys/vm/drop_caches

我自己踩过的坑是：sync 不能省。drop_caches 只是把内核里干净的缓存丢掉，如果脏页还没落盘就急着清，风险是实打实的。先 sync 把数据刷到磁盘，再 echo 3，顺序反了意义不大。

echo 1 / 2 / 3 分别释放了什么

这三个数字不是随便选的，对应内核里不同的缓存类型，选错等于没清到你想要的那部分：

• echo 1：释放 PageCache，也就是文件内容缓存
• echo 2：释放 Dentries 和 Inodes，即目录项和索引节点缓存
• echo 3：释放所有缓存，等于把上面两类一起清掉

配合 free -m 可以观察内存变化，确认清理前后 buff/cache 那一列的差异。顺带说一句，drop_caches 属于内核提供的调试接口，频繁手动执行会让系统反复重建缓存，反而拖慢热点文件的读取，别当成日常保养手段天天跑。

适用场景与选型建议

这套做法适合谁？我个人的判断是：

• 内存偏小、又跑着内存敏感型业务（比如数据库、Java 应用）的老旧服务器，临时缓解 OOM 压力可以用
• 做压测或性能对比时，需要把缓存状态拉回一致基线，清一次再测更公平
• 选购云服务器或物理机时，可以把它当作一个观察指标：如果一台机器必须靠定时清缓存才能稳住，说明内存配置本身就偏紧，选型阶段就该加内存而不是加脚本

反过来，现代 Linux 内核对缓存的管理已经相当成熟，缓存本身就是用来提升性能的，绝大多数生产环境并不需要定期清理。真遇到内存不足，优先排查是不是有进程泄漏，而不是靠 crontab 打补丁。

关键信息

• 定时清理用 crontab -e，示例为每天凌晨 2 点执行 sync 后写入 echo 3
• echo 1 释放 PageCache，echo 2 释放 Dentries 和 Inodes，echo 3 释放全部缓存
• 执行前用 sync 保证数据安全，执行后用 free -m 查看内存变化
• 定期管理缓存可以优化性能、避免缓存占用过多导致内存不足，但不建议作为常规运维手段

qidao123.com企服评测-应用市场 编辑提示

drop_caches 是应急与测试工具，不是日常保养项。选服务器时把内存余量算够，比事后写清理脚本更省心；真要上 crontab，记得先 sync 再清，并盯紧 free -m 的变化。