echo 1只清PageCache，适合释放部分内存且保留路径加速；需先sync再sudo sh -c 'echo 1 > /proc/sys/vm/drop_caches'，避免权限中断与数据丢失。
直接清 PageCache：用 echo 1 > /proc/sys/vm/drop_caches
只清页面缓存（即文件内容在内存中的副本），不影响目录结构或元数据缓存。这是最轻量、最常用的操作，适合想快速释放一部分内存又不想干扰文件系统查找路径的场景。
执行前必须先运行 sync，否则未写盘的脏页可能被丢弃，导致数据丢失。命令要分两步写，不能合并成 sync && echo 1 > ... —— 因为 echo 需要 root 权限，而 sync 不需要，混用 && 容易因权限失败中断流程。
- 推荐写法：
sync回车，等提示符回来再输sudo sh -c 'echo 1 > /proc/sys/vm/drop_caches' -
drop_caches是一次性触发器，写入后立即生效，不会持久化；值会自动回到 0 - 清完后用
free -h看buff/cache行下降，但available值未必立刻上升——内核可能马上又把空闲内存用于新缓存
为什么不能只靠 echo 1 就解决内存紧张？
PageCache 只是缓存的一部分。如果你发现 free -h 显示 buff/cache 占了十几 GiB，但 echo 1 后只少了 2–3 GiB，大概率是 dentries 和 inodes 缓存占了大头——尤其是频繁创建/删除小文件、遍历深层目录的场景（比如 CI 构建、日志轮转、容器镜像拉取）。
这些缓存不存文件内容，而是加速路径解析和 inode 查找，echo 1 对它们完全无效。
- 查证方式：运行
cat /proc/meminfo | grep -E "^(Cached|SReclaimable|Slab)"，如果SReclaimable（可回收 Slab 内存）远高于Cached，说明 dentry/inode 是主力 - 这时得用
echo 2或echo 3，但要注意：echo 2会短暂拖慢后续ls、find、open()等路径操作
drop_caches=1 的副作用和性能影响
清 PageCache 不会杀进程、不碰用户态内存，但会强制后续文件读取走磁盘——对刚清过缓存的机器做 grep、tail -f 或启动服务，延迟会明显升高。
- 典型表现：清完后第一次
cat /var/log/syslog要卡几百毫秒，第二次就快了 - 数据库、Java 应用、Redis 等自带缓存的程序基本不受影响；但依赖内核缓存做热数据加速的 Nginx 静态文件服务、rsync 备份任务会抖动
- 别在生产数据库服务器上定时跑
echo 1——它可能让 pg_buffercache 或 MySQL 的 innodb_buffer_pool 效果打折
更稳妥的替代思路：调参比清缓存更有效
频繁手动清 PageCache，往往说明内核缓存回收太保守。与其反复擦黑板，不如调低 vm.vfs_cache_pressure 让内核更主动回收 dentry/inode，或提高 vm.swappiness 把匿名页换出，给 PageCache 让路。
- 临时调参：
sudo sysctl vm.vfs_cache_pressure=200（默认 100，值越大越激进回收 inode/dentry） - 查看当前缓存压力：
cat /proc/sys/vm/vfs_cache_pressure - 真正该清缓存的信号是：
free -h中available持续低于 5% 且swpd在增长——这时候再sync && echo 3才有意义
sync 是否完成、权限是否到位、以及 echo 后面那个重定向是不是用了 sudo sh -c 包裹——少一个环节，命令就静默失败。 
