memavailable高于几百mb时无需清理缓存，因linux会自动回收；echo 3 > /proc/sys/vm/drop_caches必须前置sync以防数据丢失，且需root权限，仅释放pagecache、dentries和inodes，不触rss或活跃slab。
别急着清，先看 free -h 输出里的 MemAvailable —— 如果它还有几百 MB 以上，缓存压根不用动。Linux 的 buff/cache 是“活内存”，不是泄漏，系统缺内存时会自动回收。
为什么直接 echo 3 > /proc/sys/vm/drop_caches 很危险
这条命令本身不报错，但跳过 sync 就执行，等于强行丢弃还没写进磁盘的脏页（dirty page）。后果可能是：数据库事务丢失、日志截断、文件内容损坏。
- 必须严格按顺序执行：
sync→sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' - 不能用普通用户重定向写入：
sudo echo 3 > /proc/sys/vm/drop_caches会失败，因为重定向由 shell 执行，没权限 -
echo 3清的是三类缓存：page cache + dentries + inodes；若只想轻量释放，改用echo 1（只清文件内容缓存）更安全
清完发现内存没多多少？检查这几个地方
free -h 看到的 buff/cache 下降了，但 MemAvailable 没明显涨，常见原因有：
- 其他进程立刻占用了刚释放的内存（比如监控 agent、日志轮转脚本）
- 内核 slab 分配器里还有大量
SReclaimable（如 dentry/inode 对象），drop_caches不动这部分，需调高vm.vfs_cache_pressure长期缓解 - 有进程锁住了内存（
mlock()或memlock限制），这部分不会被drop_caches触及 - swap 正在使用中，
MemAvailable已扣减 swap 可用空间，单纯清 cache 不影响该值计算逻辑
定时清理别用 cron，用 systemd timer 更可靠
crond 在系统负载高或时间跳变时容易漏执行；systemd timer 支持 Persistent=true 和 RandomizedDelaySec，更适合生产环境。
- 脚本必须包含
sync，且用sh -c或sudo tee写入/proc/sys/vm/drop_caches - timer 文件里设
OnCalendar=hourly不如OnUnitActiveSec=3600稳定，避免跨小时边界失效 - 加一句
ConditionACPower=false（如果跑在笔记本上），防止电池模式下误触发 - 不要在
ExecStart=里连写swapoff -a && swapon -a—— 若 swap 分区正在使用，swapoff会阻塞甚至失败，导致整个 service 标记为 failed
真正难处理的从来不是缓存本身，而是缓存背后暴露的问题：比如某个服务持续申请内存却不释放、日志疯狂刷盘导致 dirty page 积压、或者 /proc/sys/vm/swappiness 设得过高引发不必要的 swap 活动。清缓存只是表象操作，盯住 MemAvailable 趋势和 vmstat 1 的 si/so（swap in/out）列，才能定位根因。
