执行 sync 之前不可直接 drop_caches，必须先运行 sync; sync; sync 确保脏页落盘，否则会导致数据丢失或文件损坏；drop_caches 各值用途不同，生产环境应优先尝试 echo 1；判断内存压力应依据 available 而非 free；echo 0 无效且无意义。
执行 sync 之前别急着写 drop_caches
直接 echo 3 > /proc/sys/vm/drop_caches 会丢数据。Linux 的 buff/cache 里可能还躺着没刷盘的脏页（比如刚写完但还没落盘的日志、数据库临时文件），不先同步就清，相当于拔硬盘前没点“安全弹出”。
必须先运行 sync，而且建议连写三次：sync; sync; sync。这不是玄学——内核有时会把部分写操作延迟排队，多跑几遍能更大程度确保所有缓冲区真正落盘。
常见错误现象：free -m 显示 buff/cache 降了，但后续发现文件损坏、MySQL 报错 InnoDB: Database page corruption，大概率就是漏了 sync 或只跑了一次。
echo 1、echo 2、echo 3 到底该选哪个
值不是越大越好，得看你要解决什么问题：
-
echo 1 > /proc/sys/vm/drop_caches：只清页缓存（PageCache），适合刚批量读完大文件、想腾出内存给新进程用，又想保留目录结构加速后续ls或open()。 -
echo 2 > /proc/sys/vm/drop_caches：只清dentries和inodes缓存，对频繁创建/删除小文件的场景（如日志轮转）有用，但不会影响文件内容读取速度。 -
echo 3 > /proc/sys/vm/drop_caches：三者全清，等效于1+2。多数人图省事用这个，但代价是下次ls /var/log或打开任意文件都会变慢——内核得重新解析路径、加载 inode。
生产环境建议优先试 echo 1；确认无效再升到 3。别一上来就 3，尤其在数据库或 NFS 挂载点附近操作。
定时脚本里别裸写 echo 3
自动清理不能只看 free 的 free 字段——它不包含 buff/cache。真正可用内存是 available 列（CentOS 7.4+ free 默认显示），或者手动算 free + buffers + cached。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
一个典型错误脚本：只判断 free 就触发清理，结果 <code>available 还有 1.2GB，硬清导致服务响应延迟 spikes。
推荐条件判断逻辑：
- 先取
available值：avail=$(free -m | awk 'NR==2 {print $7}') - 设阈值（比如 500MB）：
if [ "$avail" -le 500 ]; then ... - 执行前加
sleep 2，避免和其它 I/O 密集任务撞车
crontab 写法注意：/etc/crontab 必须带用户名（如 root），crontab -e 则不能写用户名，写错就静默失败。
清完缓存后 echo 0 不生效是正常的
/proc/sys/vm/drop_caches 是个开关，不是配置项。写 3 是发指令，写 0 并不会“关掉机制”——内核压根不支持回写 0，会报 Invalid argument。这跟系统是否重启无关。
它的值只是上次操作的残留记录，不影响后续行为。不用管它，系统照常自动管理缓存。强行 echo 0 只会让运维误以为“已恢复默认”，反而忽略真正的问题：比如某个 Java 进程泄漏堆外内存，或 rsync 没关导致持续缓存占用。
最该盯的是 available 和 swap 使用率。如果清完缓存后 available 没涨、swap 在涨，说明不是缓存问题，是程序真缺内存。
