buff/cache包含buffers和cache两类不同缓存：buffers是块设备原始数据缓存，生命周期短；cache是受lru管理的页缓存，可被进程申请随时回收。

free 命令里 buff/cache 到底算谁的内存？

free 输出里的 buff/cache 行常被误读为“可释放但没释放的闲余内存”，其实它包含两类完全不同的内核缓存：

• Buffers：块设备（如磁盘）的原始数据缓存，生命周期短，通常只存几秒，和文件系统无关
• Cache：页缓存（PageCache），即最近读写过的文件内容，受 LRU 管理，可被进程内存申请随时回收

关键判断点：只要 Available 列数值充足（远大于 0），buff/cache 高 ≠ 内存紧张。Linux 不会把这部分当“已用死”——它本质是“热数据暂存区”，不是泄露，也不是浪费。

怎么看出 Buffer 和 Cache 各自占多少？

free 默认只合并显示，得加参数拆开：

• free -h → 看总览（但不区分 Buff/Cache）
• free -h -w → 强制分列显示 Buffers 和 Cache（Linux 5.0+ 内核支持）
• 老内核（/proc/meminfo：

  Buffers:        123456 kB  
  Cached:        2345678 kB  
  SReclaimable:   987654 kB  # 包含在 Cached 里，主要是 slab 可回收部分

注意：Cached 值 ≈ PageCache + 部分 slab 缓存；SReclaimable 是其中可安全回收的部分，不是全部。

执行 sync && echo 3 > /proc/sys/vm/drop_caches 有用吗？

这命令能清掉 PageCache、dentries 和 inodes，但：

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

• sync 必须先执行，否则脏页（dirty pages）不会刷盘，drop_caches 会跳过它们
• echo 3 清的是缓存，不碰 Buffers（Buffers 由内核自动管理，无法手动清）
• 生产环境慎用：清完首次读文件会变慢，可能触发大量磁盘 I/O，影响响应延迟
• 它不能解决内存不足——如果 Available 已很低，清 cache 只是腾出几百 MB，而真正吃内存的是进程（RES），不是缓存

常见误判场景：看到 buff/cache 占 80%，就去狂清 cache，结果 top 里 RES 还在涨，问题根本不在这儿。

真实内存压力该看哪几列？

别盯着 used 或 buff/cache，重点盯三处：

• Available：内核估算的、当前可立即分配给新进程的内存（含可回收 cache），这是最靠谱指标
• MemAvailable 在 /proc/meminfo 里，和 free -h 的 Available 是同一值
• SwapUsed：如果 swap 开始上涨，说明物理内存确实不够，内核已在换出匿名页
• si/so 列（vmstat 1 输出）：持续非零说明在频繁换入换出，内存严重承压

一个典型错觉：某服务 RSS 上升到 4G，free 显示 Available 还剩 1.2G —— 这时不是 cache 占太多，而是那个进程真吃了 4G，得查 pmap -x <pid></pid> 或 cat /proc/<pid>/smaps_rollup</pid> 看它内部分配细节。

Buffer 和 Cache 的边界在内核里是清晰的，但在 free 输出里长期混在一起；老版本内核连 Available 都不报，这时候必须切到 /proc/meminfo 手动算，别信第一眼看到的数字。