直接运行free -h，第二行Mem:后的buff/cache值即当前缓冲与页缓存总和，它由Buffers+Cached+SReclaimable构成，属可自动回收内存，不计入进程RES，不代表真实占用。
怎么看缓存占了多少内存（buff/cache 字段）
直接运行 free -h，第二行 Mem: 后的 buff/cache 值就是当前用于缓冲（buffers）和页缓存（cached）的总内存。这个值通常很大，但不是“被占用”，而是可随时回收的——只要新进程申请内存，内核就会自动释放它。
-
buff/cache=Buffers+Cached+SReclaimable（slab 中可回收部分），/proc/meminfo里能拆开看 - 不要把
buff/cache和used相加去判断“总占用”——used已包含这部分，重复计算会严重高估压力 - 如果
buff/cache占比超 70% 且available持续低于 512MB，才需进一步查是否缓存堆积异常（比如日志轮转卡住、dentry 泄漏）
怎么区分 buffers 和 cache 的具体构成
想定位缓存类型（比如是文件读缓存多，还是 slab 对象多），得看 /proc/meminfo 的原始字段：
-
Buffers：块设备 I/O 的临时写缓冲，一般很小（几 MB 到百 MB），长期 >500MB 可能异常 -
Cached：文件页缓存（page cache），占buff/cache大头，正常业务下波动大 -
SReclaimable：slab 分配器中可回收的对象（如 dentry、inode），持续增长不释放可能暗示内核对象泄漏 -
Shmem：tmpfs 和共享内存用量，df /dev/shm可交叉验证
执行：cat /proc/meminfo | grep -E "^(Buffers|Cached|SReclaimable|Shmem)"
为什么 top 或 htop 里看不到 buff/cache 细节
top 和 htop 只显示整体内存视图（Mem: used/free/avail），不暴露 buff/cache 内部结构。它们的 “Mem” 行顶部数值和 free 第一行一致，但没提供拆解能力。
-
htop按 F2 → “Display options” 可勾选 “Show CPU/IO graphs”，但依然不显示 buffers/cache 分项 - 想实时观察缓存变化趋势，得靠脚本轮询
/proc/meminfo，或用vmstat 1看si/so是否因缓存回收失败而触发 swap - 误以为 “top 里 RES 加起来不到 80%，所以缓存肯定不多” —— 这是典型错觉，
buff/cache完全不计入任何进程的 RES
哪些缓存真难回收、容易被忽略
不是所有标为 “可回收” 的缓存都能立刻腾出空间。以下几类常卡住，导致 available 持续偏低：
-
SlabUnreclaimable：slab 中不可回收对象（如某些驱动分配的内存），slabtop里看ACTIVE / TOTAL比值，长期接近 100% 要警惕 - 未释放的 POSIX 共享内存：
ipcs -m查bytes列，残留的shmid不随进程退出自动清理 - tmpfs 挂载点填满：比如
/run或/dev/shm，df -h比free更早暴露问题 - mmap(MAP_LOCKED) 锁定的内存：不会计入
buff/cache，但也不参与回收，cat /proc/*/maps | grep locked可排查
真正卡住系统的，往往不是 page cache，而是这些“假缓存”。
