MemAvailable高于200MB无需清理缓存，因buff/cache是可自动回收的活内存；真正需干预仅当MemAvailable持续低于200MB、服务变慢、OOMKiller触发或日志出现“memory pressure”。
别急着写定时脚本——先看 free -h 输出里的 MemAvailable。如果它还有几百 MB 以上，缓存压根不用动。Linux 的 buff/cache 是“活内存”，不是泄漏，系统缺内存时会自动回收。
什么时候真该清理？
真正需要干预的情况很明确：MemAvailable 持续低于 200MB、服务响应变慢、OOMKiller 被触发，或日志里频繁出现 “memory pressure” 提示。单纯看到 buff/cache 占满 80% 并不构成清理理由。
- 检查命令：
free -h和cat /proc/meminfo | grep -E "^(MemAvailable|Cached|SReclaimable)" - 排除干扰：确认没有进程锁住内存（
grep -r mlock /proc/[0-9]*/status 2>/dev/null | head） - 观察趋势：用
watch -n 30 free -h看半小时内 MemAvailable 是否稳定回升
安全清理三步必须做全
直接 echo 3 > /proc/sys/vm/drop_caches 很危险——它会丢弃还没写进磁盘的脏页。数据库事务、日志追加、文件写入都可能中断。
-
第一步：强制刷盘 —— 执行
sync（建议连写三次，确保所有缓冲区落盘） -
第二步：提权写入 —— 不能用
sudo echo 3 > ...，正确写法是：sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'或echo 3 | sudo tee /proc/sys/vm/drop_caches -
第三步：选对数值 ——
echo 1只清文件内容缓存（最常用、最安全）；echo 3清全部，但影响更大
用 systemd timer 替代 cron
crond 在系统时间跳变、高负载时容易漏执行；systemd timer 支持延迟补偿、开机后补执行、电源状态判断，更适合生产环境。
- 创建 service 文件
/etc/systemd/system/clear-cache.service，内容含Type=oneshot和ExecStart=/bin/sh -c 'sync && echo 1 > /proc/sys/vm/drop_caches' - 创建 timer 文件，设
OnUnitActiveSec=3600（每小时触发一次），比OnCalendar=hourly更可靠 - 加一句
ConditionACPower=true，避免笔记本电池模式下误触发 - 启用：
sudo systemctl daemon-reload && sudo systemctl enable --now clear-cache.timer
清理后没效果？查这几个地方
脚本跑完，free -h 显示 buff/cache 下降了，但 MemAvailable 没涨？常见原因：
- 刚释放的内存立刻被监控 agent、日志轮转、定时备份等进程占满
- 内核 slab 中仍有大量
SReclaimable（如 dentry/inode 对象），drop_caches 不动这部分；可临时调高vm.vfs_cache_pressure=200加速回收 - 有进程调用
mlock()锁住内存，这部分不会被清理触及 - swap 正在使用中，MemAvailable 已扣减 swap 可用空间，清 cache 不改变该值计算逻辑
